util: drop Python 2.4 compat by directly importing md5 and sha1 There's been a fair amount of cruft here over the years, which we can all just get rid of now.

hgweb: replace some str.split() calls by str.partition() or str.rpartition() Since Python 2.5 str has new methods: partition and rpartition. They are more specialized than the usual split and rsplit, and they sometimes convey the intent of code better and also are a bit faster (faster than split/rsplit with maxsplit specified). Let's use them in appropriate places for a small speedup. Example performance (partition): $ python -m timeit 'assert "apple|orange|banana".split("|")[0] == "apple"' 1000000 loops, best of 3: 0.376 usec per loop $ python -m timeit 'assert "apple|orange|banana".split("|", 1)[0] == "apple"' 1000000 loops, best of 3: 0.327 usec per loop $ python -m timeit 'assert "apple|orange|banana".partition("|")[0] == "apple"' 1000000 loops, best of 3: 0.214 usec per loop Example performance (rpartition): $ python -m timeit 'assert "apple|orange|banana".rsplit("|")[-1] == "banana"' 1000000 loops, best of 3: 0.372 usec per loop $ python -m timeit 'assert "apple|orange|banana".rsplit("|", 1)[-1] == "banana"' 1000000 loops, best of 3: 0.332 usec per loop $ python -m timeit 'assert "apple|orange|banana".rpartition("|")[-1] == "banana"' 1000000 loops, best of 3: 0.219 usec per loop

help: replace some str.split() calls by str.partition() or str.rpartition() Since Python 2.5 str has new methods: partition and rpartition. They are more specialized than the usual split and rsplit, and they sometimes convey the intent of code better and also are a bit faster (faster than split/rsplit with maxsplit specified). Let's use them in appropriate places for a small speedup. Example performance (partition): $ python -m timeit 'assert "apple|orange|banana".split("|")[0] == "apple"' 1000000 loops, best of 3: 0.376 usec per loop $ python -m timeit 'assert "apple|orange|banana".split("|", 1)[0] == "apple"' 1000000 loops, best of 3: 0.327 usec per loop $ python -m timeit 'assert "apple|orange|banana".partition("|")[0] == "apple"' 1000000 loops, best of 3: 0.214 usec per loop Example performance (rpartition): $ python -m timeit 'assert "apple|orange|banana".rsplit("|")[-1] == "banana"' 1000000 loops, best of 3: 0.372 usec per loop $ python -m timeit 'assert "apple|orange|banana".rsplit("|", 1)[-1] == "banana"' 1000000 loops, best of 3: 0.332 usec per loop $ python -m timeit 'assert "apple|orange|banana".rpartition("|")[-1] == "banana"' 1000000 loops, best of 3: 0.219 usec per loop

convert: test clean p2 file missing 216fa1ba9993 introduced "clever" reuse of p2 but did that convert could fail with abort: f1@f73e02ae52c5: not found in manifest! when it tried to reuse a file from p2 but the file didn't exist there, for example because filemap changes. 5ca587348875 fixed that (using changes from a75d24539aba), but with a quite different reasoning and test case. Add another test that makes sure this case is covered too.

uescape: also encode non-printable char under 128 We were assuming everything under 128 was printable ascii, but there are a lot of control characters in that range that can't simply be included in json and other targets. We forcibly encode everything under 32, because they are either control char or oddly printable (like tab or line ending). We also add the hypothesis-powered test that caught this.

testing: add hypothesis fuzz testing Hypothesis a library for adding fuzzing over a range of structure data to your test suite: http://hypothesis.readthedocs.org/en/latest/ This adds the ability to build tests using Hypothesis within the Mercurial test suite. New tests and fixes using this helpers comes in later changesets.

merge with stable

Added signature for changeset 47dd34f2e727

Added tag 3.6 for changeset 47dd34f2e727

i18n: look translation of both "DEPRECATED" and "(DEPRECATED)" up Since 44cc9f63a2f1, deprecated commands, options and so on are detected by "(DEPRECATED)" instead of "DEPRECATED". "hg.pot" generated from recent source files doesn't contain msgid "DEPRECATED", and looking the translation of "DEPRECATED" up in up-to-date *.po files works incorrectly. But on the other hand, there are still old *.po files, which contain msgid "DEPRECATED" but not "(DEPRECATED)". Looking the translation of "(DEPRECATED)" up in such old *.po files also works incorrectly. This patch resolves this problem by looking translation of both "DEPRECATED" and "(DEPRECATED)" up. This should work correctly, because previous patch makes "deprecated" checker be applied only on translations, of which msgid contains exact "(DEPRECATED)" string. 'p.msgstr' examination in 'deprecatedsetup()' is needed to ignore untranslated entries. This also makes 'deprecatedpe.msgstr' examination in 'deprecated()' meaningless.

i18n: fix regexp pattern to detect translation for DEPRECATED Since 44cc9f63a2f1, deprecated commands, options and so on are detected by "(DEPRECATED)" instead of "DEPRECATED". Therefore, 'deprecated' checker in i18n/check-translation.py should check translation, of which msgid contains "(DEPRECATED)" instead of "DEPRECATED". At glance, it seems to do so, but it actually doesn't, because Python regexp treats "()" as grouping of patterns and "(DEPRECATED)" matches only against "DEPRECATED".

scmutil: abort if an empty revision is given to revpair() When using 'extdiff --patch' to check the changes in a rebase, 'precursors(x)' evaluated to an empty set because I forgot the --hidden flag, so the other revision was used as the replacement for the empty set. The result was the patch for the other revision was diffed against itself, and the tool saying there were no differences. That's misleading since the expected diff args were silently changed, so it's better to bail out. The other uses of scmutil.revpair() are commands.diff and commands.status, and it doesn't make sense to allow an empty revision there either. The code here was suggested by Yuya Nishihara.

i18n-pt_BR: synchronized with a9ed5a8fc5e0

i18n-ja: synchronized with 6474b64045fb

packaging: rework version detection and declaration (issue4912) Previously the -rc in our rc tags got dropped, meaning that those packages looked newer to the packaging system than the later release build. This rectifies the issue, though some damage may already have been done on 3.6-rc builds. I'm mostly cargo-culting the RPM version format - there don't appear to be rules for RPM about how to handle this. Hopefully an RPM enthusiast can fix up what I've done as a followup.

hgweb: escape class keyword when used as a js object property (issue4913)

localrepo: discard objects in _filecache at transaction failure (issue4876) 'repo.invalidate()' deletes 'filecache'-ed properties by 'filecache.__delete__()' below via 'delattr(unfiltered, k)'. But cached objects are still kept in 'repo._filecache'. def __delete__(self, obj): try: del obj.__dict__[self.name] except KeyError: raise AttributeError(self.name) If 'repo' object is reused even after failure of command execution, referring 'filecache'-ed property may reuse one kept in 'repo._filecache', even if reloading from a file is expected. Executing command sequence on command server is a typical case of this situation (5c0f5db65c6b also tried to fix this issue). For example: 1. start a command execution 2. 'changelog.delayupdate()' is invoked in a transaction scope This replaces own 'opener' by '_divertopener()' for additional accessing to '00changelog.i.a' (aka "pending file"). 3. transaction is aborted, and command (1) execution is ended After 'repo.invalidate()' at releasing store lock, changelog object above (= 'opener' of it is still replaced) is deleted from 'repo.__dict__', but still kept in 'repo._filecache'. 4. start next command execution with same 'repo' 5. referring 'repo.changelog' may reuse changelog object kept in 'repo._filecache' according to timestamp of '00changelog.i' '00changelog.i' is truncated at transaction failure (even though this truncation is unintentional one, as described later), and 'st_mtime' of it is changed. But 'st_mtime' doesn't have enough resolution to always detect this truncation, and invalid changelog object kept in 'repo._filecache' is reused occasionally. Then, "No such file or directory" error occurs for '00changelog.i.a', which is already removed at (3). This patch discards objects in '_filecache' other than dirstate at transaction failure. Changes in 'invalidate()' can't be simplified by 'self._filecache = {}', because 'invalidate()' should keep dirstate in 'self._filecache' 'repo.invalidate()' at "hg qpush" failure is removed in this patch, because now it is redundant. This patch doesn't make 'repo.invalidate()' always discard objects in '_filecache', because 'repo.invalidate()' is invoked also at unlocking store lock. - "always discard objects in filecache at unlocking" may cause serious performance problem for subsequent procedures at normal execution - but it is impossible to "discard objects in filecache at unlocking only at failure", because 'releasefn' of lock can't know whether a lock scope is terminated normally or not BTW, using "with" statement described in PEP343 for lock may resolve this ? After this patch, truncation of '00changelog.i' still occurs at transaction failure, even though newly added revisions exist only in '00changelog.i.a' and size of '00changelog.i' isn't changed by this truncation. Updating 'st_mtime' of '00changelog.i' implied by this redundant truncation also affects cache behavior as described above. This will be fixed by dropping '00changelog.i' at aborting from the list of files to be truncated in transaction.

demandimport: fix TypeError when importing Python regex library (issue4920)

bundle2: attribute remote failures to remote (issue4788) Before bundle2, hook output from hook failures was prefixed with "remote: ". Up to this point with bundle2, the output was converted to the message to print in an Abort exception. This had 2 implications: 1) It was unclear whether an error message came from the local repo or the remote 2) The exit code changed from 1 to 255 This patch changes the handling of error:abort bundle2 parts during push to prefix the error message with "remote: ". This restores the old behavior. We still preserve the behavior of raising an Abort during bundle2 application failure. This is a regression from pre-bundle2 because the exit code changed. Because we no longer raise an Abort with the remote's message, we needed to insert a message for the new Abort. So, I invented a new error message for that. This is another change from pre-bundle2. However, I like the new error message because it states unambiguously who aborted the push failed, which I think is important for users so they can decide what's next.

tests: add tests for remote hook output (issue4788) The added tests don't agree in their output. This demonstrates a difference in `hg push` behavior between pre-bundle2 and bundle2. A subsequent patch will attempt to restore some of the pre-bundle2 behavior to bundle2.

help: mention alias and revsetalias in description of HGPLAINEXCEPT

debugrevlog: cope with empty revlog files I have no idea where it came from, but my clone of Mercurial has an empty filelog for `contrib/hgfixes/__init__.py` - it's *valid*, just contains no nodes. Without this change, debugrevlog crashes with a zero division error.

largefiles: don't mute and obfuscate http errors when putlfile fails 'unexpected putlfile response: None' when an http error occurs is not very helpful. Instead, leave the handling of urllib2.HTTPError exceptions to other layers.

largefiles: test coverage of error handling from putlfile This reveals a wrong and unhelpful 'unexpected putlfile response'.

largefiles: check hash of files in the store before copying to working dir If the store somehow got corrupted, users could end up in weird situations that were very hard to recover from or lead to propagation of the corruption. Instead, spend the extra time checking the hash when copying to the working directory. If it doesn't match, emit a warning, and don't put wrong content in the working directory.

largefiles: test coverage of handling of store corruption This reveals that update might put a corrupted largefile in the working directory where it will show up as modified and ready for commit.

merge: improve clarity of table in update docstring

ui: support paths.default-push without paths.default set (issue4914) This behavior regressed as part of the paths API refactoring. Previous behavior was to accept "default-push" without "default" defined. Current behavior aborts with "default repository not configured!." This patch restores the old behavior and adds test coverage for the scenario, which was absent before.

bookmarks: don't allow pushing new head for existing mark with -B (issue4400)

commands: fix help for debugobsolete

largefiles: fix explicit commit of normal/largefile switch Commit of corresponding normal/largefiles pairs would only commit the standin. That is usually fine, except if either the normal file or the standin is a remove while the other is an add. In that case it would either give duplicate colliding entries or lose the file. Instead, commit both filenames if one of them is a remove.

largefiles: test coverage of explicit commit of normal/largefile switch This reveals that a switch from normal to largefile violates the normal largefile invariant and gives a manifest with both a normal and standin file in the repository, while a switch from largefile to normal gives nothing. Not good.

Added signature for changeset b66e3ca0b90c

Added tag 3.6-rc for changeset b66e3ca0b90c

merge default into stable for code freeze

convert: fix Python syntax in 'splice in' message Instead of reporting spliced in ['82544090e14fe18091e04f1fb0f0d7991cbe6e7e'] as parents of 369fd983d9e13330e9f12d9fce820deae84ea223 report spliced in 82544090e14fe18091e04f1fb0f0d7991cbe6e7e as parents of 369fd983d9e13330e9f12d9fce820deae84ea223

rebase: fix wrong 'no changes to commit' when using --collapse --collapse will do that rebase doesn't commit until the final commit. The lack of a new commit would make it look like the rebase didn't contribute any changes. Instead, only warn about no commits when not using --collapse.

pull: all pass along extra opargs Wihtout this patch, commands.pull silently drops opargs defeating the whole purpose of the argument.

push: all pass along opargs Wihtout this patch, commands.push silently drops opargs defeating the whole purpose of the argument.

check-code: allow argument passing py2.6ism this backs out 131f7fe06e9e, because Python2.5 support was dropped

mail: drop python 2.5 self.sock.read workaround

url: drop support for python2.5

win32: drop reference to python2.5

editmerge: dequote other use of $ED We want to support editors with parameters, eg EDITOR="vim -O" or whatever. So remove the quotes from around $ED and assume that the editor variable is properly escaped already.

bundlerepo: properly extract compressed changegroup from bundle2 Before this bundle repository were unable to work with compressed bundle2. We use the same approach as with bundle1, we extract the changegroup in uncompressed form into a temporary file.

bundle2: make unbundle.compressed return True when compressed We were returning 'False' in all cases, even when the bundle2 was actually compressed.

bundlerepo: uncompress changegroup in bundle1 case only Uncompressing bundle2 needs to be handled differently.

bundlerepo: move temp-bundle writing logic into a closure We will reuse this logic for bundle2

shelve: properly process bundle2 bundle

histedit: properly apply bundle2 backups If the histedit fails, we restore a backup. We make sure this backup bundle can be in bundle2 format as general delta will require.

strip: pass source and url to bundle2 processing Restoring from a 'bundle2' was missing this data.

unbundle: use 'url' argument with applybundle This will let the hook get access to the 'url' value.

applybundle: take url as argument We allow specifying the url to carry it to hooks. This gets us closer to 'bundle1.apply(...)' and will allow us to remove regressions in multiple place where we forget to pass the url to hooks.

unbundle: use 'source' argument with applybundle This will let the hook get access to the 'source' value.

applybundle: take source as argument We allow specifying the source to carry it to hooks. This gets us closer to 'bundle1.apply(...)' and will allow us to remove regressions in multiple places where we forget to pass the source to hooks.

applybundle: set 'bundle2=1' env for all transaction This should be set for all bundle2 application, we enforce that at a low level. This is for courtesy with hooks.

unbundle: use 'bundle2.applybundle' This is one such place.

bundle2: introduce an "applybundle" function There is a case where the intent is clear and the transaction is not optional. We want to be able to alter that transaction in a wide and easy way. We cannot get a unified '.apply(repo)' method for bundle1 and bundle2 yet because the api are still a bit too far apart. But this is a good step forward to get the rc out.

commands.resolve: conclude merge driver if no unresolved files are left This can happen when either 'hg resolve --all' is called or a driver-resolved file is explicitly requested. This is done as part of 'hg resolve --all' so that users still have a chance to test their changes before committing them. The exact semantics here are still to be decided. This does not impact any non-experimental features. Thanks to Pierre-Yves David for some advice about this behavior in particular, and merge drivers in general.

commands.resolve: call driverpreprocess if we haven't run it yet We need to be careful about allowing --mark and --unmark to keep working -- we don't want the user to be stuck in a weird state. The exact behavior here is still to be decided, though.