parsers: use base-16 trie for faster node->rev mapping This greatly speeds up node->rev lookups, with results that are often user-perceptible: for instance, "hg --time log" of the node associated with rev 1000 on a linux-2.6 repo improves from 0.3 seconds to 0.03. I have not found any instances of slowdowns. The new perfnodelookup command in contrib/perf.py demonstrates the speedup more dramatically, since it performs no I/O. For a single lookup, the new code is about 40x faster. These changes also prepare the ground for the possibility of further improving the performance of prefix-based node lookups.

check-code: avoid false-positive on ++

graphlog: cleanup before code move - Avoid revset module aliasing - Mark makefilematcher() private

graphlog: correctly handle calls in subdirectories

context: revert workingctx.ancestors() followfirst option It was introduced by mistake in 352053e6cd8e.

graphlog: fix --follow-first --rev combinations This solves a similar problem than the previous --follow/--rev patch. This time we need changelog.ancestors()/descendants() filtering on first parent. Duplicating the code looked better than introducing keyword arguments. Besides, the ancestors() version was already implemented in follow() revset.

graphlog: fix --follow --rev combinations The previous behaviour of --follow was really a subset of what is really happening in log command: - If --rev is not passed, default to '.:0' - Resolve --rev into a revision list "revs" - Set the starting revision to revs[0] - If revs[1] > revs[0] keep descendants(revs[0]) in revs, otherwise keep ancestors.

graphlog: support changeset identifiers in --branch

graphlog: pass changesets to revset.match() in changelog order Running: $ time hg debugrevspec 'user(mpm)' | wc on Mercurial repository takes 1.0s with a regular version and 1.8s if commands.debugrevspec() is patched to pass revisions to revset.match() from tip to 0. Depending on what we expect from the revset API and caller wisdom, we might want to push this change in revset.match() later.

graphlog: refactor revset() to return revisions When --follow and --rev are passed, --follow actual behaviour depends on the input revision sequence defined by --rev. If --rev is not passed, the default revision sequence depends on the presence of --follow. It means the revision sequence generation is part of log logic and must be wrapped. The issue described above is fixed in following patches.