[PATCH 0 of 5] transaction fixes to make strip more corruption safe

[Henrik Stuart]

Benoit Boissinot skrev:
> On Fri, Apr 24, 2009 at 11:42:32AM +0200, Henrik Stuart wrote:
>> Resend of patch series without the fsync part.
> 
> part 1-4 pushed to crew (with some rework):
> 8289:fe8a3e56039f
> 8290:560af1bbfd6e
> 8291:f5c1a9094e41
> 8292:29540554def8
> 8293:f00573bc93f8
> 8294:48a382c23226
> 
> part 5 will need some work regarding the backwards compat.

Part 5 concerns adding a grouping around operations made by strip, e.g.
a simple strip operation today will add the following to a journal:

00changelog.i\0offset_c
00manifest.i\0offset_m
data/file1.i\0offset1
data/file2.i\0offset2
...
data/filen.i\0offsetn

If something happens in the middle of writing the journal (e.g., user
presses ctrl+c) the journal will remain and on the subsequent activity
on the repository will suggest hg recover, which then will proceed to
strip the entries in the journal and leave the rest of the files in an
inconsistent state.

The proposed patch adds an atomic group around these entries, e.g.:

begin atomic
00changelog.i\0offset_c
00manifest.i\0offset_m
data/file1.i\0offset1
data/file2.i\0offset2
...
data/filen.i\0offsetn
end atomic

and on the absence of end atomic, the group will not be processed, thus
not corrupting the repository.

This will, as Benoit mentioned, cause older clients trying to process a
journal from a newer version to crash, but no harm will be done
otherwise, i.e. the journal will not disappear, and the need to run hg
recover will not disappear.

Should this be considered a problem and the logic be made more rigorous
for gracefully failing older clients? E.g. by extending the requires
features on the repository? Or should it be apparent that it is probably
a bad idea to suddenly downgrade the client and expect everything to
automatically still work?

-- 
Kind regards,
  Henrik Stuart