transaction: include backup file in the "undo" transaction Once the transaction is closed, we now write transaction related data for possible future undo. For now, we only do it for full file "backup" because their were not handle at all in that case. In the future, we could move all the current logic to set undo up (that currently exists in localrepository) inside transaction itself, but it is not strictly requires to solve the current situation.

transaction: pass the name of the "undo" journal to the transaction It is time for the transaction to be responsible for setting up the undo data. It is necessary to move this logic into the transaction because many more files are handled now, and the transaction is the object tracking them all. The value can be set to None if no undo should be set.

rollback: have an empty entry for the vfsmap in rollback This empty string key is used for the store. This will be needed to properly rollback backup in a future changesets.

transaction: clarify the name of 'journal' argument for transaction The argument is a string containing the journal name (used as prefix for all other transaction file). This is not the transaction file itself. So we clarify this.

transaction: use 'util.copyfile' for creating backup Using 'copyfile' (single file) instead of 'copyfiles' (tree) will ensures destination file will be overwritten. This will prevent some abort if backup file are left in place for random reason. It also seems more correct.

copyfile: allow optional hardlinking Some code paths use 'copyfiles' (full tree) for a single file to take advantage of the best-effort-hard-linking parameter. We add similar parameter and logic to 'copyfile' (single file) for this purpose. The single file version have the advantage to overwrite the destination file if it exists.

repair: add experimental option to write bundle2 files This adds an experimental option 'strip-bundle2-version' which causes backup bundles to use bundle2 formatting. Especially for generaldelta repositories, this should provide significant performance gains for any operation that needs to write a backup.

changegroup.getsubset: support multiple versions Allow a version parameter to specify which version of the packer should be used

changegroup.writebundle: HG2Y support This diff adds support to writebundle to generate a bundle2 wrapper; upcoming diffs will add an option to write a v2 changegroup part instead of v1 in these bundles.

changegroup.writebundle: provide ui The next diff will add support for writing bundle2 files to writebundle, but the bundle2 generator wants access to a ui object. This changes the signature and callsites to pass one in.

test-module-imports: use test-repo requirement

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.