merge with stable

tags: create new sortdict for performance reasons sortdict internally maintains a list of keys in insertion order. When a key is replaced via __setitem__, we .remove() from this list. This involves a linear scan and array adjustment. This is an expensive operation. The tags reading code was calling into sortdict.__setitem__ for each tag in a read .hgtags revision. For repositories with thousands of tags or thousands of .hgtags revisions, the overhead from list.remove() noticeable. This patch creates a new sortdict() so __setitem__ calls don't incur a list.remove. This doesn't appear to have any performance impact on my Firefox repository. But that's only because tags reading doesn't show up in profiles to begin with. I'm still waiting to hear from a user with over 10,000 tags and hundreds of heads on the impact of this patch.

largefiles: specify where .orig files are kept This patch let's the user specify where .orig files are kept using the cmdutil.origpath function

mq: let the user choose where .orig files are kept This patch uses cmdutil.origpath to let the user decide where .orig files are kept when backup files are created.

shelve: choose where .orig file locations are kept This patch uses cmdutil.origpath to let the user set the location of the orig files.

filemerge: choose where .orig files are kept Having .orig files litter your working copy is a common complaint. This patch uses cmdutil.orig to let the user determine where those files should reside.

git-subrepos: revert respects specified location to save .orig files This patch makes revert in git subrepos save .orig files where the user wants them by using the cmdutil.origpath function.

resolve: choose where .orig file locations are kept Having your working copy littered with .orig files is a common HG complaint. This patch uses the cmd.origpath helper function to let the user specify where they should be kept when using the resolve command.

revert: allow configuring the .orig file location

cmdutil: add origbackuppath helper

discovery: pass pushop to _nowarnheads Previously, we passed only enough information to _nowarnheads to perform the old calculation. However, extensions may want to use more information in this calculation. Now that pushop is extensible, extensions will often want access to the additional fields they have added to the pushop, so pass that through. Specifically, the remotenames extension will use this information to allow pushing new heads that are bookmarked without requiring --force.

exchange: pass pushop to discovery.checkheads Previously, we passed a bunch of parameters to discovery.checkheads, but all of the arguments can be fetched out of pushop, which may contain a lot more useful information for extensions now that pushop is extensible.

merge with stable

share: wrap bmstore._writerepo for transaction sensitivity (issue4940) 46dec89fe888 made 'bmstore.write()' transaction sensitive, to restore original bookmarks correctly at failure of a transaction. For example, shelve and unshelve imply steps below: before 46dec89fe888: 1. move active bookmark forward at internal rebasing 2. 'bmstore.write()' writes updated ones into .hg/bookmarks 3. rollback transaction to remove internal commits 4. restore updated bookmarks manually after 46dec89fe888: 1. move active bookmark forward at internal rebasing 2. 'bmstore.write()' doesn't write updated ones into .hg/bookmarks (these are written into .hg/bookmarks.pending, if external hook is spawn) 3. rollback transaction to remove internal commits 4. .hg/bookmarks should be clean, because it isn't changed while transaction running: see (2) above But if shelve or unshelve is executed in the repository created with "shared bookmarks" ("hg share -B"), this doesn't work as expected, because: - share extension makes 'bmstore.write()' write updated bookmarks into .hg/bookmarks of shared source repository regardless of transaction activity, and - intentional transaction failure at the end of shelve/unshelve doesn't restore already updated .hg/bookmarks of shared source This patch makes share extension wrap 'bmstore._writerepo()' instead of 'bmstore.write()', because the former is used to actually write bookmark changes out.

test: use generaldelta in 'test-clonebundle.t' Using generaldelta has effects on the generated bundle.