exchange: pass bundlecaps through to changegroup The bundlecaps passed to exchange.getbundle were being dropped completely. We should pass them on through to the changegroup. This affected the remotefilelog extension, since it relies on those bundlecaps.

bundle2: allow pulling changegroups using bundle2 This changeset refactors the pull code to use a bundle2 when available. We keep bundle2 disabled by default. The current code is not ready for prime time. Ultimately we'll want to unify the API of `bunde10` and `bundle20` to have less different code. But for now, testing the bundle2 exchange flow is an higher priority.

bundle2: add an exchange.getbundle function This function can return a `HG10` or `HG20` bundle. It uses the `bundlecaps` parameters to decides which one to return. This is a distinct function from `changegroup.getbundle` for two reasons. First the APIs of `bundle10` and `bundle20` are not compatible yet. The two functions may be reunited in the future. Second `exchange.getbundle` will grow parameters for all kinds of data (phases, obsmarkers, ...) so it's better to keep the changegroup generation in its own function for now. This function will be used it in the next changesets.

localpeer: propagate bundlecaps in getbundle call Best arguments are the ones in use...

bundle2: make it possible have a global transaction for the unbundling We use the `gettransaction` method approach already used for pull. We need this because we do not know beforehand if the bundle needs a transaction to be created. And (1) we do not want to create a transaction for nothing. (2) Some bundle2 bundles may be read-only and do not require any lock or transaction to be held.

tests: fix test output typo

bundle2: first crude version of bundling changeset with bundle2 The current changegroup format is put in a "changegroup" part and processed by an appropriate handlers. This is not production ready code, but let us start smoke testing.

bundle2: record processing results in the bundleoperation object Part handlers can now add records to the `bundleoperation` object. This can be used to help other parts or to let the caller of the unbundling process react to the results.

bundle2: introduce a bundleoperation object This object will hold all data and state gathered through the processing of a bundle. This will allow: - each handler to be aware of the things unbundled so far - the caller to retrieve data about the execution - bear useful object and logic (like repo, transaction) - bear possible bundle2 reply triggered by the unbundling. For now the object is very simple but it will grow at the same time as the bundle2 implementation.

bundle2: feed a unbundle20 to the `processbundle` function The unbundle can comes from multiple sources. (on disk file, peer, etc) and (ultimately) of multiple type (bundle10, bundle20). The `processbundle` is no longer in charge of creating the bundle.

bundle2: lock the repo during unbundle test We forgot the lock the repo. It's not too bad during tests, but the lock also still carry some transaction logic. (yes we need to get rid of this)

merge: keep destination filename as key in filemerge actions Gives more readable debug output and makes it possible to compare/merge actions later.

merge: keep destination filename as key in actions for merge with dir rename Avoids None: local renamed directory to b/c -> d updating:None 1/1 files (100.00%) and makes it possible to compare/merge actions later.

merge: include ancestor node in merge actions

merge with stable

repoview: use _gethiddenblockers in computehidden No functionality has changed, since we've only extracted the code into its own function. Now extensions can wrap _gethiddenblockers to provide their own blocker without polluting bookmarks or local tags.

repoview: add _gethiddenblockers method This is a standalone function that will provide the ability for extensions to wrap.

repoview: improve performance for computehidden (issue4206) For repos with a large number of heads (including hidden heads), a stale tag cache would cause computehidden to be drastically slower because of a the call to repo.tags() (which would build the tag cache). We actually don't need the tag cache for computehidden because we filter out global tags. This patch replaces the call to repo.tags with readlocaltags so as to avoid the tag cache.

tests: remove unused variables from test-pathencode.py caught by pyflakes

shelve: remove unused variable caught by pyflakes

changegroup: remove unused variable caught by pyflakes

hgk: use hg export to write commits Instead of calling internal command, use hg export to produce changeset diffs compatible with hg import directly.

hgk: add .diff extension when exporting commits Append the .diff extension automatically.

localrepo: move the addchangegroup method in changegroup module This is a gratuitous code move aimed at reducing the localrepo bloatness. The method had few callers, not enough to be kept in local repo.

localrepo: move the addchangegroupfiles method in changegroup module This is a gratuitous code move aimed at reducing the localrepo bloatness. The method had a single caller, far too few for being kept in local repo.

localrepo: move the changegroup method in changegroup module This is a gratuitous code move aimed at reducing the localrepo bloatness. The method had few callers, not enough to be kept in local repo. The peer API stay unchanged.

localrepo: move the getbundle method in changegroup module This is a gratuitous code move aimed at reducing the localrepo bloatness. The method had few callers, not enough to be kept in local repo. The peer API remains unchanged.

store: drop unused existing list

localrepo: move the getlocalbundle method in changegroup module This is a gratuitous code move aimed at reducing the localrepo bloatness. The method had 3 callers total, far too few for being kept in local repo.

localrepo: move the changegroupsubset method in changegroup module This is a gratuitous code move aimed at reducing the localrepo bloatness. The method had few callers, not enough to be kept in local repo. The peer API remains unchanged.