Durham Goode <durham@fb.com> [Tue, 25 Mar 2014 14:10:01 -0700] rev 20894
revset: improve _descendants performance
Previously revset._descendants would iterate over the entire subset (which is
often the entire repo) and test if each rev was in the descendants list. This is
really slow on large repos (3+ seconds).
Now we iterate over the descendants and test if they're in the subset.
This affects advancing and retracting the phase boundary (3.5 seconds down to
0.8 seconds, which is even faster than it was in 2.9). Also affects commands
that move the phase boundary (commit and rebase, presumably).
The new revsetbenchmark indicates an improvement from 0.2 to 0.12 seconds. So
future revset changes should be able to notice regressions.
I removed a bad test. It was recently added and tested '1:: and reverse(all())',
which has an amibiguous output direction. Previously it printed in reverse order,
because we iterated over the subset (the reverse part). Now it prints in normal
order because we iterate over the 1:: . Since the revset itself doesn't imply an
order, I removed the test.
Durham Goode <durham@fb.com> [Mon, 31 Mar 2014 16:29:39 -0700] rev 20893
revsetbenchmark: remove python 2.7 dependency
revsetbenchmark.py used check_output which only exists in python 2.7. This
fixes it.
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 24 Mar 2014 17:20:15 -0700] rev 20892
bundle2: read the whole bundle from stream on abort
When the bundle processing abort on unknown mandatory parts, we now makes sure
all the bundle content is read. This avoid leaving the communication channel in
an unrecoverable state.
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 24 Mar 2014 13:02:02 -0700] rev 20891
bundle2: add some distinction between mandatory and advisory part
Mandatory part cannot be ignored when unknown. We raise a simple KeyError
exception when this happen.
This is very early version of this logic, see inline comment for future
improvement lead.
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 24 Mar 2014 15:51:00 -0700] rev 20890
bundle2: introduce a `parthandler` decorator
Simple syntax sugar to register an handler for a new part type.
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 24 Mar 2014 12:25:33 -0700] rev 20889
bundle2: first version of a bundle processing
We now have a function that interpret part content.
This is a version early version of this function. It'll see major changes in
scope and API in future development. As for previous I'm just focussing on
getting minimal logic setup. Refining will happen with real world usage.
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 24 Mar 2014 11:27:00 -0700] rev 20888
bundle2: rename unbundle2 test command to statbundle2
We will introduce object to actually process the bundle, we need to keep the
simplistic unbundle around for the test.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 01 Apr 2014 00:08:15 -0700] rev 20887
bundle2: safely read unpack data from part header
We use the same approach that the other unpack, as function is given the struct
format and his both responsible for reading the right amount of data from the
header and unpack the struct.
This give use flexibility if we decide to change the size of something in the
format before the release.
Matt Mackall <mpm@selenic.com> [Wed, 02 Apr 2014 13:41:23 -0500] rev 20886
transaction: drop extra import caught by pyflakes
Durham Goode <durham@fb.com> [Mon, 24 Mar 2014 15:43:15 -0700] rev 20885
fncache: clean up fncache during strips
Previously the fncache was cleaned up at read time by noticing when it was out
of sync. This caused writes to happen outside the scope of transactions and
could have caused race conditions. With this change, we'll keep the fncache
up-to-date as we go by removing old entries during repair.strip.
Durham Goode <durham@fb.com> [Mon, 24 Mar 2014 15:35:07 -0700] rev 20884
caches: invalidate store caches when lock is taken
The fncache was not being properly invalidated each time the lock was taken, so
in theory it could contain old data from prior to the caller having the lock.
This changes it to be invalidated as soon as the lock is taken (same as all our
other caches).
Durham Goode <durham@fb.com> [Mon, 24 Mar 2014 15:42:13 -0700] rev 20883
fncache: move fncache writing to be in a transaction
Previously the fncache was written at lock.release time. This meant it was not
tracked by a transaction, and if an error occurred during the fncache write it
would fail to update the fncache, but would not rollback the transaction,
resulting in an fncache that was not in sync with the files on disk (which
causes verify to fail, and causes streaming clones to not copy all the revlogs).
This uses the new transaction backup mechanism to make the fncache transacted.
It also moves the fncache from being written at lock.release time, to being
written at transaction.close time.