- Feb 13, 2012
-
-
Patrick Mézard authored
The previous code was assuming a default context of 3 lines. When fuzzing, it would take this value in account to reduce the amount of removed line from hunks top or bottom. For instance, if a hunk has only 2 lines of bottom context, fuzzing with fuzz=1 would do nothing and with fuzz=2 it would remove one of those lines. A hunk with one line of bottom context could not be fuzzed at all. patch(1) has apparently no such restrictions and takes the fuzz level at face value. - test-import.t: fuzz/offset changes at the beginning of file are explained by the new fuzzing behaviour and match patch(1) ones. Patching locations are different but those of my patch(1) do not make a lot of sense right now (patched output are the same) - test-import-bypass.t: more agressive fuzzing makes a patching supposed to fail because of context, succeed. Change the diff to avoid this. - test-mq-merge.t: more agressive fuzzing would allow the merged patch to apply with fuzz, but fortunately we disallow this behaviour. The new output is kept. I have not enough experience with patch(1) fuzzing to know whether aligning our implementation on it is a good or bad idea. Until now, it has been the implementation reference. For instance, "qpush" tolerates fuzz (test-mq-merge.t runs the special case of pushing merge revisions where fuzzing is forbidden).
-
Patrick Mézard authored
When applying hunks such as: @@ -2,1 +2,2 @@ context +change fuzzing would empty the "old" block and make patchfile.apply() traceback. Instead, we apply the new block at specified location without testing. The "bottom hunk" test was removed as patch(1) has no problem applying hunk with no context in the middle of a file.
-
Patrick Mézard authored
- It moves hunks processing weirdness where it belongs - It helps reusing said weirdness whenever fuzzit() is called, like during the actual hunk fuzzing.
-
Patrick Mézard authored
In theory, the fuzzed offsets for old and new lines should be exactly the same as they are based on hunk parsing. Make it true in practice.
-
- Feb 14, 2012
-
-
Patrick Mézard authored
Only the first imported one was pushed.
-
- Feb 15, 2012
-
-
Patrick Mézard authored
Splicemap lines are documented in hg help convert like: key parent1, parent2 but parsed like: key, parents = line.strip().rsplit(' ', 1) parents = parents.replace(',', ' ').split() The rsplit() call was introduced to handle spaces in keys for the generic mapfile format. Spaces can appear in svn identifiers since they contain path components. This logic makes less sense with splicemap since svn identifiers can also appear on the right side, even if it is a bit less likely. Given the parsing is theorically broken, I would rather follow what is documented already and is correct in the main case where all identifiers are hg hashes. Also, using svn identifiers in a splicemap sounds difficult as they are not easily accessible.
-
Idan Kamara authored
-
Idan Kamara authored
Files are being replaced by rollback but the corresponding data in localrepo isn't actually updated for things like bookmarks, phases, etc. Then when rollback is done, the cache is updated thinking it has the most up-to-date data, where in fact it is still pre-rollback. We clear _filecache to force everything to be recreated.
-
Idan Kamara authored
When assigning a new object to filecached properties, the cached object that was kept in the _filecache map was still holding the old object. By implementing __set__, we track these changes too and update the cached copy as well.
-
Idan Kamara authored
The dirstate is invalidated separately outside of invalidate() which is already being called (other callers of invalidate() seems to suggest the separation is there for a reason).
-
Idan Kamara authored
-
- Feb 16, 2012
-
-
Patrick Mézard authored
There is no reason to discard copy sources from the set of files considered by addremove(). It was done to handle the case where a first patch would create 'a' and a second one would move 'a' to 'b'. If these patches were applied with --no-commit, 'a' would first be marked as added, then unlinked and dropped from the dirstate but still passed to addremove(). A better fix is thus to exclude removed files which ends being dropped from the dirstate instead of removed. Reported by Jason Harris <jason@jasonfharris.com>
-
Patrick Mézard authored
-
- Feb 15, 2012
-
-
Katsunori FUJIWARA authored
current 'lfiles_repo.status()' implementation examines whether specified patterns are related to largefiles in working directory (not to STANDIN) or not by NOT-EMPTY-NESS of below list: [f for f in match.files() if f in lfdirstate] but it can not be assumed that all in 'match.files()' are file itself exactly, because user may only specify part of path to match whole under subdirectories recursively. above examination will mis-recognize such pattern as 'not related to largefiles', and executes normal 'status()' procedure. so, 'hg status' shows '?'(unknown) status for largefiles in working directory unexpectedly. this patch examines relation of pattern to largefiles by applying 'match()' on each entries in lfdirstate and checking wheter there is no matched entry. it may increase cost of examination, because it causes of full scan of entries in lfdirstate. so this patch uses normal for-loop instead of list comprehensions, to decrease cost when matching is found.
-
- Feb 10, 2012
-
-
Matt Mackall authored
Not only does this eat all available memory for some users, it's slower.
-
Matt Mackall authored
This bit a number of people.
-
Patrick Mézard authored
When sorting revisions before converting them, we have to edit the revision graph using splicemap entries. Otherwise, a spliced revision may be converted before its synthetic parents. Invalid splicemap revisions are now detected before starting the conversion.
-
Patrick Mézard authored
Parsing the splicemap as a mapfile was a pain because map does not let us override its parsing code and splicemap entries are not key/values. Besides we had no need for mapfiles extra features. Just parse the splicemap and return a dictionary.
-
Na'Tosha Bard authored
This fixes a serious performance regression in largefiles introduced in Mercurial 2.1. Caching new largefiles on pull is necessary, because otherwise largefiles will be missing (and unable to be downloaded) when the user tries to merge or rebase a new head with an old one. But this is an expensive operation and should only be done for heads that are new from the pull, rather than on all heads in the repository.
-
- Feb 07, 2012
-
-
Patrick Mézard authored
Since a5917346c72e, mq saves the nodeid of the first applied patch to cache/branchheads, which breaks the optimized cache handling introduced in fbf8320f25c8. The problem is the revision being committed is appended to mqrepo.applied after the commit succeeds, which means mqrepo._branchtags() performs a regular update and write the first applied patch to the branch cache. One solution is to set a context variable _committingpatch on the mqrepo while it is committing a patch and to take it in account when deciding to fast-path mqrepo._branchtags(). Not really elegant but it works. The changes to test-mq-caches.t reverse changes introduced by a5917346c72e. The cache should not have been updated with mq records. The changes to test-keyword.t are indirectly caused by a5917346c72e. Reported and analyzed by Yuya Nishihara <yuya@tcha.org> Notes: - qpush still makes a slow path _branchtags() call when checking heads. Maybe this can be optimized. - be careful when merging this patch in default as secretcommit() was renamed newcommit() right after the end of the code freeze.
-
Patrick Mézard authored
Having a common code path helps fixing things globally.
-
- Feb 08, 2012
-
-
Jim Hague authored
printf on AIX default shell ksh (89) says \1 is an invalid escape. It insists on at least 2 digits. This causes failures in test-keyword.t and test-status.t. check-code.py already looks out for \NNN and recommends using Python for outputting octal values. Extend the check to \NN and \N and fix up resulting failures.
-
- Feb 06, 2012
-
-
Matt Mackall authored
We already verify the working directory is "clean" before starting so there's no advantage to clobbering the working directory.
-
Patrick Mézard authored
When diffing the following documents with --ignore-blank-lines (-B): $ cat > a <<EOF > > > > b > x > d > EOF and: $ cat > b <<EOF > b > y > d > EOF the context lines are taken from the first document, even if the lines differ (with -w or -b) or if the number of lines differ (with -B). In the second case, we have to adjust the hunk new lines offsets or we end with inconsistent diffs like (see the @@ offsets): diff -r 0e66aa54f318 a --- a/a +++ b/a @@ -1,4 +1,3 @@ b -x +y d Note that having different context lines in a and b means the diff can be applied but is not invertible. Reported by Nicholas Riley <com-selenic@sabi.net>
-
Matt Mackall authored
-
Wagner Bruna authored
-
Wagner Bruna authored
-
Wagner Bruna authored
-
- Feb 04, 2012
-
-
Wagner Bruna authored
-
Wagner Bruna authored
-
- Feb 03, 2012
-
-
Jim Hague authored
If fixws() is called on a zero-length string, malloc(0) is called and expected to return a pointer. Which it does on e.g. Linux. AIX returns NULL, which it is also legal, but the malloc() is then assumed to have failed. So ensure a valid pointer is always returned.
-
- Feb 06, 2012
-
-
Katsunori FUJIWARA authored
in 'cmdutil.forget()': for f in match.files(): if match.exact(f) or not explicitonly: .... is equal to: for f in match.files(): if True: .... because 'f' from 'match.files()' should 'match.exact(f)': - 'match.files()' returns 'self._files' - 'match.exact(f)' examines 'f in self._fmap', - 'self._fmap' of match is 'set(self._files)' then, 'explicitonly' wants to suppress warning messges, if it is true (= 'cmdutil.forget()' is invoked from 'subrepo.forget()'). so, current code should be fixed as: if not explicitonly: for f in match.files(): ....
-
- Feb 04, 2012
-
-
Jim Hague authored
"<command> `hg manifest`" overflows the puny 1024 byte command line length limit on AIX default shell ksh. Replace with "hg manifest | xargs <command>".
-
- Feb 05, 2012
-
-
Katsunori FUJIWARA authored
-
Katsunori FUJIWARA authored
some problematic encodings use backslash as part of multi-byte characters. util.pconvert() can treat strings in such encodings correctly, if win32mbcs is enabled, but str.replace() can not.
-
Katsunori FUJIWARA authored
some problematic encodings use backslash as part of multi-byte characters. util.pconvert() can treat strings in such encodings correctly, if win32mbcs is enabled, but str.replace() can not.
-
- Feb 03, 2012
-
-
Patrick Mezard authored
The current behaviour is to return the previous one in the series but at the same time the implementation is buggy because it does not take guarded patches in account.
-
Patrick Mezard authored
When all remaining patches are guarded, qnext used to return the last of the queue anyway.
-
Patrick Mezard authored
- The regular sed on OSX wants: -i "" not -i"" - GNU sed wants: -i"" not -i "" Backups are fine.
-
- Feb 01, 2012
-
-
Matt Mackall authored
-