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.
Durham Goode <durham@fb.com> [Mon, 24 Mar 2014 15:21:51 -0700] rev 20882
transaction: add support for non-append files
This adds support for normal, non-append-only files in transactions. For
example, .hg/store/fncache and .hg/store/phaseroots should be written as part of
the transaction, but are not append only files.
This adds a journal.backupfiles along side the normal journal. This tracks which
files have been backed up as part of the transaction. transaction.addbackup()
creates a backup of the file (using a hardlink), which is later used to recover
in the event of the transaction failing.
Using a seperate journal allows the repository to still be used by older
versions of Mercurial. A future patch will use this functionality and add tests
for it.
Durham Goode <durham@fb.com> [Mon, 24 Mar 2014 15:57:47 -0700] rev 20881
transaction: add onclose/onabort hook for pre-close logic
Adds an optional onclose parameter to transactions that gets called just before
the transaction is committed. This allows things that build up data over the
course of the transaction (like the fncache) to commit their data.
Also adds onabort. It's not used, but will allow extensions to hook into onclose
and onabort to provide transaction support.
Durham Goode <durham@fb.com> [Mon, 24 Mar 2014 15:38:20 -0700] rev 20880
clone: put streaming clones in a transaction
Streaming clones were writing to files outside of a transaction. Soon the
fncache will be written at transaction close time, so we need streaming clones
to be in a transaction.
Durham Goode <durham@fb.com> [Mon, 24 Mar 2014 15:31:47 -0700] rev 20879
fncache: remove the rewriting logic
The fncache could rewrite itself during a read operation if it noticed any
entries that were no longer on disk. This was problematic because it caused
Mercurial to perform write operations outside the scope of a lock or
transaction, which could interefere with any other pending writes.
This will be replaced in a future patch by logic that cleans up the fncache
as files are deleted during strips.