Tue, 16 Apr 2013 10:08:20 -0700 revlog: don't cross-check ancestor result against Python version
Bryan O'Sullivan <bryano@fb.com> [Tue, 16 Apr 2013 10:08:20 -0700] rev 18989
revlog: don't cross-check ancestor result against Python version
Tue, 16 Apr 2013 10:08:20 -0700 parsers: a C implementation of the new ancestors algorithm
Bryan O'Sullivan <bryano@fb.com> [Tue, 16 Apr 2013 10:08:20 -0700] rev 18988
parsers: a C implementation of the new ancestors algorithm The performance of both the old and new Python ancestor algorithms depends on the number of revs they need to traverse. Although the new algorithm performs far better than the old when revs are numerically and topologically close, both algorithms become slow under other circumstances, taking up to 1.8 seconds to give answers in a Linux kernel repo. This C implementation of the new algorithm is a fairly straightforward transliteration. The only corner case of interest is that it raises an OverflowError if the number of GCA candidates found during the first pass is greater than 24, to avoid the dual perils of fixnum overflow and trying to allocate too much memory. (If this exception is raised, the Python implementation is used instead.) Performance numbers are good: in a Linux kernel repo, time for "hg debugancestors" on two distant revs (24bf01de7537 and c2a8808f5943) is as follows: Old Python: 0.36 sec New Python: 0.42 sec New C: 0.02 sec For a case where the new algorithm should perform well: Old Python: 1.84 sec New Python: 0.07 sec New C: measures as zero when using --time (This commit includes a paranoid cross-check to ensure that the Python and C implementations give identical answers. The above performance numbers were measured with that check disabled.)
Tue, 16 Apr 2013 10:08:19 -0700 revlog: choose a consistent ancestor when there's a tie
Bryan O'Sullivan <bryano@fb.com> [Tue, 16 Apr 2013 10:08:19 -0700] rev 18987
revlog: choose a consistent ancestor when there's a tie Previously, we chose a rev based on numeric ordering, which could cause "the same merge" in topologically identical but numerically different repos to choose different merge bases. We now choose the lexically least node; this is stable across different revlog orderings.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -3 +3 +10 +30 +100 +300 +1000 +3000 +10000 +30000 tip