Page MenuHomePhabricator

revlog: make transaction handle revlog splits better (issue6423)
AbandonedPublic

Authored by valentin.gatienbaron on May 16 2021, 3:31 PM.

Details

Reviewers
indygreg
Group Reviewers
hg-reviewers
Summary

Currently, any transaction that includes a revlog split and does not
successfully commit prevents any further write to the repository
(short of performing manual surgery), because it leaves behind a
transaction that hg doesn't know how to rollback.

This teaches hg how to handle such transactions. Specifically, any
interruption outside of a tight window (rename + two writes) results
in transactions that can be rolled back correctly. An interruption in
that window inside that window leaves a broken repository, similarly
to before this change.

One awkward thing is that if an old hg version leaves behind one of
these transactions it can't rollback, an hg with this change would
manage to roll it back, but wrongly (it would end up with non inline
revlog and .d file of size 0). That seems acceptable to me, because
this is a strange scenario (and either way, the solution is to
reclone).

Another awkward thing is that the fncache fails to be updated. This
seems acceptable, because it's not used much, and I'll take the
occcasional call to hg debugrebuildfncache over a broken repository.

Diff Detail

Repository
rHG Mercurial
Branch
default
Lint
No Linters Available
Unit
No Unit Test Coverage