largefiles status: update lfdirstate with result from cleanliness check Problem: 'hg status' kept checking largefiles with an unknown state until some other command wrote the updated dirstate. Solution: Add missing lfdirstate.write().

bundlerepo: don't return the peer without bundlerepo from getremotechanges Problem: getremotechanges would return the 'other' repo if nothing was incoming and there thus wasn't any bundle to base the repo on. The 'other' could be a http peer which only implement the functionality available over the http protocol. Transplant could thus fail with TypeError: argument of type 'httppeer' is not iterable Solution: Return the local repo instead of the remote peer if there is no reason to place a bundlerepo on top of the local repo.

strip: do not update branchcache during strip (issue3745) At this moment, the cache is invalid, and will be thrown away. Later the strip function will call the `localrepo.destroyed` method that will update the branchmap cache.

copies: do not track backward copies, only renames (issue3739) The inverse of a rename is a rename, but the inverse of a copy is not a copy. Presenting it as such -- in particular, stuffing it into the same dict as real copies -- causes bugs because other code starts believing the inverse copies are real. The only test whose output changes is test-mv-cp-st-diff.t. When a backwards status -C command is run where a copy is involved, the inverse copy (which was hitherto presented as a real copy) is no longer displayed. Keeping track of inverse copies is useful in some situations -- composability of diffs, for example, since adding "a" followed by an inverse copy "b" to "a" is equivalent to a rename "b" to "a". However, representing them would require a more complex data structure than the same dict in which real copies are also stored.

copies: make debug messages more sensible The -> in debug messages is currently overloaded to mean both source to dest and dest to source. To fix this, we add explicit labels and make the arrow direction consistent.

copies: separate moves via directory renames from explicit copies Currently the "copy" dict contains both explicit copies/moves made by a context and pending moves that need to happen because the other context moved the directory the file was in. For explicit copies, the dict stores a destination to source map, while for pending moves via directory renames, it stores a source to destination map. The merge code uses this fact in a non- obvious way to differentiate between these two cases. We make this explicit by storing these pending moves in a separate dict. The dict still has a source to destination map, but that is called out in the docstring.

merge with stable

branchmap: move validity logic in the object itself In several place, We check if a branchcache is still valid regarding the current state of the repository. This changeset puts this logic in a method of the object that can be reused when necessary. A branch map is considered valid whenever it is up to date or a strict subset of the repository state. The change will help making branchcache aware of filtered revision. The change in keyword is expected. the branch cache is actually invalid after the amend. The previous check did not detected it.

branchmap: make update a method

branchmap: make update responsible to update the cache key The update function have all necessary data to keep the branchcache key up to date with its value. This saves assignment to the cache key that each caller of update had to do by hand. The strip case is a bit more complicated to handles from inside the function but I do not expect any impact.

branchmap: factorise changelog access in update This both improves readability and performance. Access to changelog of filtered repository currently have a minor overhead.

branchmap: make write a method on the branchmap object

branchmap: simplify write signature All necessary data (cache value and key) are now stored in the branchcache object. Any extra parameter is superfluous.

branchmap: add the tiprev (cache key) on the branchmap object The actual cache key used on disk is the (tipnode, tiprev) pair. There is no reason not to use the revision number for the in memory version.

branchmap: add the tipnode (cache key) on the branchcache object Gathering data and cache key paves the way to a lot of simplification.

branchmap: store branchcache in a dedicated object Value and key of branchcache would benefit from being hold by the same object. Moreover some logic (update, write, validation) could be move on such object. The creation of this object is the first step toward this move. The result will clarify branchcache related code and hide most of the detail in the class itself. This encapsulation will greatly helps implementation of branchcache for filtered view of the repo.

branchmap: `stream_in` write remote branchcache to local one The previous code was writing it to a non existent `branchcache` attribute. We now write is to the proper `_branchcache` attribute and initialize the `_branchcachetip` at the same time. We keep writing it to disk, the previous code had this part right.

bookmarks: fix head selection for merge with two bookmarked heads A type mismatch caused the search for the other head to fail. The code is fragile, and instead it ended up using the 'first' bookmark head, but the ordering is undefined and it could thus randomly use the wrong bookmarkhead and fail with: $ hg up -q -C e@diverged $ hg merge abort: merging with a working directory ancestor has no effect

branchmap: extract updatebranchcache from repo

branchmap: extract _updatebranchcache from repo

branchmap: _updatebranchmap does not need to be filtered The `_updatebranchmap` method on repo does not need to be filtered as all callers are already handling filtering themself. The fact it is filtered may had even lead to buggy behaviors, but by chances the method make very sparse use of the repo object.

branchmap: extract read logic from repo

branchmap: extract write logic from localrepo

branchmap: create a mercurial.branchmap module This is the foundation stone for an extraction of branches map logic from local repository class. Most of the branches map logic have very few caller and therefor does not fit in the current criteria for code held by the localrepo class. Important change will be made to this code in relation with revision filtering. So we extract it in a dedicated module before adding additional complexity. Follow up commit do the actual code movement.