Noel Yap's recent post about ClearCase and CVS,
with the consensus being that neither CC nor CVS
directly support atomic multifile transactions
(in the sense that, if an error occurs, the entire
transaction is undone - both CVS and CC apparently
can have some files committed and others not)
leads me to the following:
How can one truly implement an atomic multifile
commit in CVS? In the sense that only a consistent
set of files is made available for others to pick up,
even in the presence of (some) errors during checkin?
I think the following comes close.
(1) Edit files, and check them in.
[Errors may occur here, leaving some files checked
in and others not. No matter.]
(2) Once all of the files are checked in, label them
CONSISTENT-date-uniqueid.
[Errors may occur here, leaving some files labelled,
and others not.]
(3) Once all of the files are labelled CONSISTENT-date-uniqueid
edit a special file CONSISTENT, and add the CONSISTENT-date-uniqueid
label to it.
(4) Have any tool that needs to get a consistent contour
read the CONSISTENT file and extract the label.
Argument (pseudo-proof):
Errors may occur in steps (1) and (2), leaving some files checked
in and others not, or some labelled and others not. This doesn't matter.
All we really need is atomicity on the checkin of the CONSISTENT file
in step (3), which CVS and CC provide.
I'm not sure if it corresponds to 2 Phase Commit or 3 Phase Commit
in the database sense. I think its 3PC, but CVS can have errors
that leave the CVS repository unusable, e.g. globally locked, or
a particular file locked, unless there is manual intervention.
The CONSISTENT file may contain only a single label,
or it might contain a timesorted sequence of labels.
