merge with stable

commands: move bundle type validation earlier Checking the bundle type late in the command's execution can mean that we do work for a long time before complaining about incorrect user input and aborting. Guess how I discovered this.

changegroupsubset: optimize function lookup in prune

changegroup: optimize gennodelist

revlog: drop some unneeded rev.node calls in revdiff

revlog: avoid an expensive string copy This showed up in a statprof profile of "hg svn rebuildmeta", which is read-intensive on the changelog. This two-line patch improved the performance of that command by 10%.

changegroupsubset: avoid setdefault in inner loop

changegroupsubset: drop repeated len() calls

changegroup: reduce progress overhead

changegroupsubset: renest inner loop The mdata list should generally be shorter than changedfiles

revlog: increase readahead size

revset: avoid demandimport bug Apparently the "import x as xy" doesn't manage to update xy in the current scope's dictionary after load, which causes nodemod.nullrev to do a huge amount of demandload magic in the inner loop.

mq: replace hasattr() with util.safehasattr(), update check-code.py

merge with stable

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.