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
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.