Mercurial: Changelog

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.