Tue, 17 Jul 2012 17:31:29 +0200 obsolete: add an any successors function
Pierre-Yves David <pierre-yves.david@logilab.fr> [Tue, 17 Jul 2012 17:31:29 +0200] rev 17213
obsolete: add an any successors function This function yield every nodes which succeed to a group of nodes. The first user will be checkheads who need to know if we push successors for remote extra heads.
Tue, 17 Jul 2012 18:14:16 +0200 checkheads: extract bookmark computation from the branch loop
Pierre-Yves David <pierre-yves.david@logilab.fr> [Tue, 17 Jul 2012 18:14:16 +0200] rev 17212
checkheads: extract bookmark computation from the branch loop No branch specific data are used in the computation of the bookmarked heads. We can only compute it once.
Tue, 17 Jul 2012 16:30:42 +0200 checkheads: simplify the structure build by preprocessing
Pierre-Yves David <pierre-yves.david@logilab.fr> [Tue, 17 Jul 2012 16:30:42 +0200] rev 17211
checkheads: simplify the structure build by preprocessing All useful data are now gathered in a single dictionnary. `branchmapsummary` is renamed to `headssummary` and its return value is greatly simplified.
Tue, 17 Jul 2012 16:16:17 +0200 _updatebranchcache: prevent deleting dict key during iteration
Pierre-Yves David <pierre-yves.david@logilab.fr> [Tue, 17 Jul 2012 16:16:17 +0200] rev 17210
_updatebranchcache: prevent deleting dict key during iteration We use dict.keys() to fetch all keys before starting to delete some. Otherwise python complains that the dictionnary is altered during iteration.
Tue, 17 Jul 2012 18:21:49 +0200 checkheads: extract branchmap preprocessing
Pierre-Yves David <pierre-yves.david@logilab.fr> [Tue, 17 Jul 2012 18:21:49 +0200] rev 17209
checkheads: extract branchmap preprocessing The checkheads function is far too complicated. This extract help to explicite what part of the preprocessing are reused by the actual check. This the first step toward a wider refactoring.
Mon, 16 Jul 2012 17:56:50 +0200 obsolete: mark unreachable extinct changesets as hidden
Pierre-Yves.David@ens-lyon.org [Mon, 16 Jul 2012 17:56:50 +0200] rev 17208
obsolete: mark unreachable extinct changesets as hidden The repo.hiddenrevs set is updated with all extinct() changesets which aren't descendants of either: - the current working copy, - a bookmark, - a tag.
Mon, 16 Jul 2012 17:44:46 +0200 hidden: move hiddenrevs set on the repository
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 16 Jul 2012 17:44:46 +0200] rev 17207
hidden: move hiddenrevs set on the repository This set is always accessed through the repo for now. Having this set carried by the changelog make it complicated to: - initialize it, computing hidden set may involve revset call - lazy compute it, (1) only the changelog can detect someone access it, (2) only the repo have enought knowledge to compute it. In later version I expect he changelog to apply filtering itself and the set to be carried by changelog again.
Fri, 13 Jul 2012 14:38:49 +0200 obsolete: do not exchange extinct changesets
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 13 Jul 2012 14:38:49 +0200] rev 17206
obsolete: do not exchange extinct changesets Extinct changesets are excluded from all exchange operations. This is a silent exclusion because the user should not need to be aware of them. There is no reason to strongly enforce this exclusion except implementation simplicity. User should be able to explicitly request an extinct changeset in the future.
Tue, 17 Jul 2012 01:22:31 +0200 repo: move visibleheads and visiblebranchmap logic in discovery
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 17 Jul 2012 01:22:31 +0200] rev 17205
repo: move visibleheads and visiblebranchmap logic in discovery They were previously inside the mercurial.phases module, but obsolete logic will need them to exclude `extinct` changesets from pull and push. The proper and planned way to implement such filtering is still to apply a changelog level filtering. But we are far to late in the cycle to implement and push such a critical piece of code (changelog filtering). With Matt Mackall approval I'm extending this quick and dirty mechanism for obsolete purpose. Changelog level filtering should come during the next release cycle.
Tue, 17 Jul 2012 01:04:45 +0200 localpeer: return only visible heads and branchmap
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 17 Jul 2012 01:04:45 +0200] rev 17204
localpeer: return only visible heads and branchmap Now that we have localpeer, we can apply filtering on heads and branchmap the same way it's done for wireprotocol peer.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip