checkheads: take future obsoleted heads into account If we push some successors they will likely create a new head on remote. However as the obsoleted head will disappear after the push we are not really increasing the number of heads. There is several case which will lead to extra being actually pushed. But this first changeset aims to be simple. See the inline comment for details. Without this change, you need to push --force every time you want to push a newer version which is very error prone. The remote side still display +n heads on unbundle because it does not have the obsolete marker at unbundle time.

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.

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.

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.

_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.

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.

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.

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.