discovery: factor out calculation of heads to not warn about In addition to taking a step towards getting an unreasonably large function factored into smaller, more manageable functions, this will allow extensions such as remotenames have more control over what pushes are allowed or not.

hooks: back 9f272bf3b342 out Changeset 9f272bf3b342 alters the 'HG_PENDING' mechanism to be "always" there. This change is made under the assumption than we previously did it only when "writepending() actually wrote something". This assumption was wrong, 'writepending()' informs of pending changes the first time something is written and for all following calls. We back this change out to restore the former behavior, which was already correct.

merge with stable

hooks: fix hooks not firing if prechangegroup was set (issue4934) We need to call delayupdate again after writing to the changelog. Otherwise the prechangegroup hook consumes the delayupdate subscription and future hooks don't see the pending changes (see issue 4934 for more details). Adds a test that triggers the prechangegroup hook before the pretxnchangegroup hook and verifies that the output of pretxnchangegroup doesn't change.

hooks: always include HG_PENDING Previously we would only include HG_PENDING in the hook args if the transaction's writepending() actually wrote something. This is a bad criteria, since it's possible that a previous call to writepending() wrote stuff and the hooks want to still see that. The solution is to always have hooks execute within the scope of the pending changes by always putting HG_PENDING in the environment.

wireproto: move clonebundles command from extension (issue4931) The SSH peer class accesses wireproto.commands[cmd] as part of encoding command arguments. Previously, the wire protocol command was defined in the clonebundles extension. If the client didn't have this extension enabled (which it likely doesn't since it is meant as a server-side extension), then clients attempting to clone via ssh:// would get a crash due to a KeyError accessing wireproto.commands['clonebundles'] when cloning from a server that is advertising clone bundles. Moving the definition of the wire protocol command to wireproto.py makes this problem go away. A side effect of this code move is servers will always respond to "clonebundles" wire protocol command requests. This should be fine: the server will return an empty response unless a clone bundles manifest file is present and clients shouldn't call the command unless the server is advertising the capability, which only happens if the clonebundles extension is enabled and the manifest file exists.

templatefilters: try round-trip utf-8 conversion by json filter (issue4933) As JSON string is known to be a unicode, we should try round-trip conversion for localstr type. This patch tests localstr type explicitly because encoding.fromlocal() may raise Abort for undecodable str, which is probably not what we want. Maybe we can refactor json filter to use encoding module more later. Still "{desc|json}" can't round-trip because showdescription() modifies a localstr object.

exchange: do not attempt clone bundle if local repo is non-empty (issue4932)

test-clonebundles.t: add test for incremental pull This demonstrates issue4932.

i18n: make sure to include translation of (DEPRECATED) This patch replaces old "DEPRECATED" msgid by "(DEPRECATED)" if that .po file does not have "(DEPRECATED)" but have "... (DEPRECATED)". It is necessary to hide deprecated options correctly.

i18n: do not abuse msgstr of "DEPRECATED" to check for bad translation Because 44cc9f63a2f1 requires the msgstr of "(DEPRECATED)", old *.po files must be blamed. Using "DEPRECATED" would just hide the error. For example, "LANG=da_DK.UTF-8 hg help serve" fails to hide deprecated options right now, but check-translation.py couldn't detect it because da.po has outdated translation of "DEPRECATED".

filemerge.prompt: separate out choice selection and action This will make future patches cleaner.

test-merge-prompt.t: add tests for linear updates + change/delete conflicts Turns out this bit of code was woefully untested.

test-pathencode.py: drop support for Python 2.4

hgweb.server: drop support for Python 2.4

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.