Siddharth Agarwal <sid0@fb.com> [Mon, 26 Nov 2012 11:02:48 -0800] rev 17971
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.
Siddharth Agarwal <sid0@fb.com> [Mon, 26 Nov 2012 11:46:51 -0800] rev 17970
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
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Fri, 23 Nov 2012 11:59:44 -0500] rev 17969
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.
Bryan O'Sullivan <bryano@fb.com> [Tue, 27 Nov 2012 14:58:00 -0800] rev 17968
subrepo: use posixpath when diffing, for consistent paths
This fixes a Windows failure in test-subrepo-recursion.t introduced
by
c84ef0047a94.
Bryan O'Sullivan <bryano@fb.com> [Tue, 27 Nov 2012 13:09:05 -0800] rev 17967
run-tests: fix an unnoticed check-code violation
Bryan O'Sullivan <bryano@fb.com> [Tue, 27 Nov 2012 11:18:33 -0800] rev 17966
run-tests: add a --compiler option
Without this option, it is not possible to run the test suite on Windows
using mingw's gcc as the compiler.
Bryan O'Sullivan <bryano@fb.com> [Tue, 27 Nov 2012 11:18:31 -0800] rev 17965
run-tests: make build command line less intimidating
Use a dict for parameters to the format string, instead of a
ridiculous number of positional parameters.
Matt Mackall <mpm@selenic.com> [Mon, 26 Nov 2012 17:48:39 -0600] rev 17964
hooks: be even more forgiven of non-fd descriptors (
issue3711)
Looks like there are instances where sys.stdout/stderr contain file
handles that are invalid. We should be tolerant of this for hook I/O
redirection, as our primary concern is not garbling our own output stream.
Matt Mackall <mpm@selenic.com> [Mon, 26 Nov 2012 16:14:22 -0600] rev 17963
hooks: delay I/O redirection until we actually run a hook (
issue3711)
We were attempting to redirect I/O even if no hook was actually
getting called. This defers redirection until we've found something to
do.
Matt Mackall <mpm@selenic.com> [Mon, 26 Nov 2012 15:42:52 -0600] rev 17962
util: make chunkbuffer non-quadratic on Windows
The old str-based += collector performed very nicely on Linux, but
turns out to be quadratically expensive on Windows, causing
chunkbuffer to dominate in profiles.
This list-based version has been measured to significantly improve
performance with large chunks on Windows, with negligible overall
overhead on Linux (though microbenchmarks show it to be about 50% slower).
This may increase memory overhead where += didn't behave quadratically. If we
want to gather up 1G of data to join, we temporarily have 1G in our
list and 1G in our string.