[PATCH 0 of 6] fixing last corruption issue with strip

Henrik Stuart hg at hstuart.dk
Tue Apr 21 12:33:19 CDT 2009


These six patches are, largely, the last part of making strip safe 
transactionally/recoverably.

Patch 1 ensures that the journal file is synced to disk. Without this, the
following scenario might happen:

  tr.add(filename, offset, data)
  fileh.write(newdata)
  tr.add(filename2, offset2, data2)
  # sync of the above two adds happens here, but fails
  fileh2.write(newdata2)

Now extraneous "dead" data is located in filename with no apparent feedback
that it ought to be removed.

Patch 2 adds a decorator to all methods in the transaction class that expects
the transaction to be alive when invoked. This is exclusively to catch
programming mistakes rather than user mistakes.

Patch 3 ensures that internal book-keeping variables are reset on an abort as
well. Otherwise, an aborted transaction could potentially be used as if it was
not disposed.

Patch 4 is not directly concerned with the transaction things, but it prevents
a crash in hg verify that patch 5 uncovered.

Patch 5 refactors the transaction.rollback function and
transaction.transaction.abort methods to use, more or less, the same code.
In keeping with the current functionality, abort does not unlink files.

Finally, patch 6 adds atomic blocks to the transaction such that either all
of the atomic items are evaluated, or none of them are. This is only really
relevant for strip operations where everything has to be done. Remember, the
recovery of a failed strip is to complete the strip, there is no way to
restore the data with the current form of the transaction (as opposed to the
more normally known database transactions).


More information about the Mercurial-devel mailing list