test-mq-qrefresh: test that the patch at qtip is indeed empty ...after qrefreshing a non-existent file

tests: only call check-code once The accepted warnings list is now empty, let's try to keep it that way.

ancestor: fix a comment (followup to 0b03454abae7)

revlog: allow reverse iteration with revlog.revs We often need to perform rev iteration in reverse order. This changeset makes it possible to do so, in order to avoid costly reverse or reversed() calls later.

convert: add config option to use the local time zone The default for the time zone offset in a converted changeset has always been 0 (UTC). With this patch, the converted changeset is modified so that the local offset from UTC is specified as the time zone offset. The option is specified as the boolean convert.localtimezone (default False). Example usage: hg convert -s cvs --config convert.localtimezone=True example-cvs example-hg IMPORTANT: the patch only applies to conversions from cvs or svn. The documentation for the option only appears in those two sections in the convert help text.

rebase: use revlog.findmissingrevs to compute detach set

revlog: add rev-specific variant of findmissing This will be used by rebase in an upcoming commit.

revlog: switch findmissing to use ancestor.missingancestors This also speeds up other commands that use findmissing, like incoming and merge --preview. With a large linear repository (>400000 commits) and with one incoming changeset, incoming is sped up from around 4-4.5 seconds to under 3.

ancestor: faster algorithm for difference of ancestor sets One of the major reasons rebase is slow in large repositories is the computation of the detach set: the set of ancestors of the changesets to rebase not in the destination parent. This is currently done via a revset that does two walks all the way to the root of the DAG. Instead of doing that, to find ancestors of a set <revs> not in another set <common> we walk up the tree in reverse revision number order, maintaining sets of nodes visited from <revs>, <common> or both. For the common case where the sets are close both topologically and in revision number (relative to repository size), this has been found to speed up rebase by around 15-20%. When the nodes are farther apart and the DAG is highly branching, it is harder to say which would win. Here's how long computing the detach set takes in a linear repository with over 400000 changesets, rebasing near tip: Rebasing across 4 changesets Revset method: 2.2s New algorithm: 0.00015s Rebasing across 250 changesets Revset method: 2.2s New algorithm: 0.00069s Rebasing across 10000 changesets Revset method: 2.4s New algorithm: 0.019s

bisect: add example for limiting bisection to specified directories The bisect command does not have an option to limit itself only to subdirectories, but it's possible to use revsets for the --skip option for the same effect. Given the relative obscurity of revsets, it helps to have this as another example for bisect.