Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 21 Mar 2023 15:44:38 +0000] rev 50317
debugdeltachain: stop summing the same chain over and over
Before this patch, delta chain size was computed from scratch for each chain,
disregarding the fact very likely already computed the same of length-1 prefix
for another revisions.
We not cache delta chain size and shortcut the computation when we see them.
Just for my mercurial-devel clone, this move the computation from about 17.5
second to about 4.8 seconds.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Mar 2023 11:52:17 +0100] rev 50316
revlog: improve the robustness of the splitting process
The previous "in-place" splitting, preserving the splitting on transaction
failure had a couple of issue in case of transaction rollback:
- a race windows that could still lead to a crash and data loss
- it corrupted the `fncache`.
So instead, we use a new approach that we summarized as "we do a backup of the
inline revlog pre-split, and we restore this in case of failure".
To make readers live easier, we don't overwrite the inline index file until
transaction finalization. (once the transaction get into its finalization phase,
it is not expected to rollback, unless some crash happens).
To do so, we write the index of the split index in a temporary file that we use
until transaction finalization. We also keep a backup of the initial inline file
to be able to rollback the split if needed.
As a result, transaction rollback cancel the split and no longer corrupt
fncache. We also no longer have a small inconsistency windows where the
transaction could be unrecoverable.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Mar 2023 11:40:18 +0100] rev 50315
fncache: make it possible to ignore some file
In the next changeset, we need to able to ignore some temporary file. This
changeset teach the fncache about that.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Mar 2023 11:09:03 +0100] rev 50314
revlog: test that pending hooks properly see the repository on split
This seems important to explicitly cover this case before changing the code.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 17 Mar 2023 02:46:51 +0100] rev 50313
revlog: test possible read race condition with splitting
This is currently working fine, but could break with another approach (for
example, with the one we are about to use in the next changesets…)
So we make sure the case is covered.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 16 Mar 2023 21:04:52 +0100] rev 50312
revlog: add a failing variant of the the split + transaction test
We have another variant to tests, and it is crashing… So lets cover it with
tests.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 16 Mar 2023 20:37:11 +0100] rev 50311
revlog: update the split + transaction test
We add section, increase the amount of comments and simplify some of the
constructs. We are about to build more on top this tests so lets do a small
cleanup first.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Mar 2023 14:29:37 +0100] rev 50310
transaction: allow to backup file that already have an offset
This will be useful in the next changeset to deal with rolling back the split of
inline revlog on transaction failure.
This involve deeper change to the transaction logic as we need to make sure we
restore the backup -before- the truncation step. Otherwise, the truncation
would act on the wrong file and be overwritten by the backup restoration later.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Mar 2023 13:20:12 +0100] rev 50309
transaction: move the restoration of backup file in a small closure
We are about to use that logic in two different location, making is a small
reusable closure prepares that.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Mar 2023 12:13:08 +0100] rev 50308
transaction: raise on backup restoration error
A few line above, similar errors in the truncation code result in raising the
associated exception. We should do the same here.
This means the transaction recover is more strict now, which might be a problem
when running `hg recover` in a share different from the one where the
transaction fails. However this has always been a problem and need to be be
addressed independently.