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.

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.

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.

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.

util, posix: eliminate encodinglower and encodingupper 2ebe3d0ce91d claims this was needed "to avoid cyclic dependency", but there is no cyclic dependency. windows.py already imports encoding, posix.py can import it too, so we can simply use encoding.upper in windows.py and in posix.py. (this is a partial backout of 2ebe3d0ce91d)

hgweb: side-by-side comparison functionality Adds new web command to the core, ``comparison``, which enables colorful side-by-side change display, which for some might be much easier to work with than the standard line diff output. The idea how to implement comes from the SonicHq extension. The web interface gets a new link to call the comparison functionality. It lets users configure the amount of context lines around change blocks, or to show full files - check help (also in this changeset) for details and defaults. The setting in hgrc can be overridden by adding ``context=<value>`` to the request query string. The comparison creates addressable lines, so as to enable sharing links to specific lines, just as standard diff does. Incorporates updates to all web related styles. Known limitations: * the column diff is done against the first parent, just as the standard diff * this change allows examining diffs for single files only (as I am not sure if examining the whole changeset in this way would be helpful) * syntax highlighting of the output changes is not performed (enabling the highlight extension has no influence on it)

scmutil: 25% speedup in casecollisionauditor On a large repository, switching casecollisionauditor to lowercasing all file names at once rather than one at a time improves hg-add time by 25%.

obsolete: os.SEEK_END first appeared in Python 2.5 fixes 48c232873a54 failing for Python 2.4

tests: convert a push test to use revsets

outgoing: accept revset argument for --rev There may be a more generic way that would add revset support to more commands by adding revset support to addbranchrevs(), but given the proximity of the next code freeze, a minimal change seems like the better choice.

dirstate: drop assert

dirstate: eliminate redundant check parameter on _addpath() state == 'a' implies check I fail to see what the point of this check parameter is. Near as I can see, the only _addpath call where it was set to True was in add(), but there, state is 'a'. This is a follow-up to c2016bae3b97.

obsolete: add seek to end of file before calling tell (issue3543)

peer: remove cancopy from peer api; use directly on repo instead

peer: introduce canpush and improve error message

peer: introduce real peer classes This change separates peer implementations from the repository implementation. localpeer currently is a simple pass-through to localrepository, except for legacy calls, which have already been removed from localpeer. This ensures that the local client code only uses the most modern peer API when talking to local repos. Peers have a .local() method which returns either None or the underlying localrepository (or descendant thereof). Repos have a .peer() method to return a freshly constructed localpeer. The latter is used by hg.peer(), and also to allow folks to pass either a peer or a repo to some generic helper methods. We might want to get rid of .peer() eventually. The only user of locallegacypeer is debugdiscovery, which uses it to pose as a pre-setdiscovery client. But we decided to leave the old API defined in locallegacypeer for clarity and maybe for other uses in the future. It might be nice to actually define the peer API directly in peer.py as stub methods. One problem there is, however, that localpeer implements lock/addchangegroup, whereas the true remote peers implement unbundle. It might be desireable to get rid of this distinction eventually.

peer: introduce peer methods to prepare for peer classes This introduces a peer method into all repository classes, which currently simply returns self. It also changes hg.repository so it now raises an exception if the supplied paths does not resolve to a localrepo or descendant. Finally, all call sites are changed to use the peer and local methods as appropriate, where peer is used whenever the code is dealing with a remote repository (even if it's on local disk).

bookmarks: document behavior of -B/--bookmark in help

test-bookmarks-pushpull.t: verify correct push -B behavior I wasn't able to find a test that proved this behavior worked, so I felt obligated to write a quick test so it won't regress in the future.