largefiles: don't rehash largefiles in updatelfiles if standin hash changed Standins are read before and after an update/merge, and all the standins that changes are handed to updatelfiles for getting their corresponding largefiles updated. updatelfiles would then hash the largefile and see if it already matched the new expected hash. If so, it would skip the update. If different, the largefile would be updated. It would happen very rarely that the largefile happened to match the new hash (and thus not the old one) and the hashing would thus be pointless ... and hashing is not cheap. Instead, when it is known that the standin hash changed (from an update), just update the standin unconditionally. If the largefile was "unsure" before the update, it was hashed at that point, so we know there is nothing to preserve. (Also, the hashing in updatelfiles was not used to preserve changes, but only to be lazy about updating the largefile, so nothing is lost by not doing this extra hashing.) There might be rare situations where we now will update largefiles that didn't have to be updated, but in all relevant cases (?) this will improve performance. Updates on a repo with some big largefiles has been seen to go from 9.19 s to 6.8 s - that is 26% less painful.

largefiles: show progress when checking standin hashes in outgoing changesets This checking can take a huge amount of time and we should give user a hint that something is going on.

unbundle: support bundle2 files This adds support for bundle2 files to the unbundle command.

pullbundle2: extract addchangegroup result combining into its own function This will also be used for 'hg unbundle'

histedit: add a test to show that issue4251 is fixed (issue4251) This will help us not regress this case in the future.

commands.debugbundle: bundle2 support This enables debugbundle to print supporting info for bundle2 files.

largefiles: cleanup overrideadd() This was a remnant of the code prior to overridding cmdutil.add().

largefiles: enable subrepo support for add The --large, --normal and --lfsize args couldn't be passed to a subrepo before, and files in the subrepos would be added silently (if -v wasn't specified) as normal files. As an added bonus, 'hg add --dry-run' no longer prints that largefiles would also be added as normal files as well.

add: pass options via keyword args The largefiles extensions needs to be able to pass --large, --normal and --lfsize to subrepos via cmdutil.add() and hgsubrepo.add(). Rather than add additional special purpose arguments, stop extracting the existing args from the **opts passed to commands.add() and just pass them along.

largefiles: don't pop largefile-specific arguments to the add command The arguments will need to stay present when making add work with subrepos.

share: replace the bookmarks.shared file with an entry on a new "shared" file cd79fb4d75fd introduced a way to share bookmarks. When a repository share that shares bookmarks was created, a .hg/bookmarks.shared file was created to mark the repository share as one that shares its bookmarks. We have plans to introduce other levels of sharing, including a "full share" mode. Rather than creating a new ".shared" file for each new thing that we may want to share It seems better to create a single "shared" file that will list what is shared for a given shared repository. This should make it much easier to get a list of everything that is shared by a given shared repository. The shared file contains a list of shared "items" (such as bookmarks). Each shared "item" is added as a new line in the file. For now the only possible entry in the file is "bookmarks".

docker: support Fedora 21

rpm: make Python 2.7.9 the default Python to include in rpms for EL 5 Use the new and more TLS support in Python 2.7.9.

contrib: make Python 2.7.9 the default in Makefile.python We should utilize (and test) the big API changes and new TLS functionality in Python 2.7.9 whenever possible.

localrepo: remove all external users of localrepo.wopener This change touches every module in which repository.wopener was being used, and changes it for the equivalent repository.wvfs. It should now be possible to remove localrepo.wopener.

localrepo: remove all external users of localrepo.sopener This change touches every module in which repository.sopener was being used, and changes it for the equivalent repository.svfs. It should now be possible to remove localrepo.sopener.

localrepo: remove all external users of localrepo.opener This change touches every module in which repository.opener was being used, and changes it for the equivalent repository.vfs. This is meant to make it easier to split the repository.vfs into several separate vfs. It should now be possible to remove localrepo.opener.

log: use namespace logname and colorname Now that we have the machinary to change the log name and the color label used, let's use that. Tests have been updated accordingly.

namespaces: add colorname member to namespace object Previously, there was no way to change the color label used for 'hg log' output. This patch just adds the member to the object, a future patch will change 'hg log' to use this.

namespaces: add logname member to namespace object Previously, there was no way to change the name used for 'hg log' output. This was inconvenient for extensions that want a template name longer than 12 characters (e.g. remotebookmarks) but a different name for 'hg log'. This patch only adds the member to the object, a future patch will update the 'hg log' code.

namespaces: use named args for namespace api This is just a style change but makes adding new arguments more robust for callers.

namespaces: make the constructor into named args None of the arguments are truly optional but this makes adding future arguments more robust and perhaps optional.

dispatch: only check compatibility against major and minor versions (BC) Extensions can declare compatibility with Mercurial versions. If an error occurs, Mercurial will attempt to pin blame on an extension that isn't marked as compatible. While all bets are off when it comes to the internal API, my experience has shown that a monthly/patch release of Mercurial has never broken any of the extensions I've written. I think that expecting extensions to declare compatibility with every patch release of Mercurial is asking a bit much and adds little to no value. This patch changes the blame logic from exact version matching to only match on the major and minor Mercurial versions. This means that extensions only need to mark themselves as compatible with the major, quarterly releases and not the monthly ones in order to stay current and avoid what is almost certainly unfair blame. This will mean less work for extension authors and almost certainly fewer false positives in the blame attribution.

test-extension: use a realistic Mercurial version Mercurial doesn't define the 3rd "patch" version field for major releases. Don't use it in tests.

test-extension: improve test readability There was a mountain of text in this file that made reading the tests difficult. Inserting some line breaks greatly improves the situation.

bundle2: enforce parttype as alphanumerical The binary format description has always stated that the parttype should be simple, but it was never really enforced. Recent discussions have convinced me we want to keep the part type simple and easy to debug. There is enough extensibility in the rest of the format.

tests: conditionalize test-tools.t for Windows support I still get the following diff on Windows 7 with NTFS. I'm not sure if it is expected and we should wildcard the link count, or if something needs to be fixed. @@ -58,7 +58,7 @@ $ ln bar baz $ f bar -n baz -l --hexdump -t --sha1 --lines=9 -B 20 - bar: file, links=2, newer than baz, sha1=612ca68d0305c821750a + bar: file, links=0, newer than baz, sha1=612ca68d0305c821750a\r (esc) 0000: 31 0a 32 0a 33 0a 34 0a 35 0a 36 0a 37 0a 38 0a |1.2.3.4.5.6.7.8.| 0010: 39 0a |9.|

dirstate: ignore negative debug.dirstate.delaywrite values - they crashed it Sleep can only travel forward in time, not back.