Atomicity idea.

[Kaz Kylheku]

I'm looking at the CVS source code, and thinking about ways to make
commits and tagging atomic.

One idea is to do it in a lower layer, and perform only minimal
instrumentation of the CVS logic: basically insert a few calls to the
transactional layer into a few key places in CVS.

That lower layer would replace the POSIX filesystem functions with
ones that support transactions. The idea is that the application can
call a special function which starts a transaction. It then executes
arbitrary filesystem mutating calls: writing to files, renaming
temporary files to permanent ones, and so on. The transaction is then
terminated with an abort or commit. If the machine dies during the
transaction, then it's as if the transaction never happened. If the
client socket dies (client was killed by SIGINT or whatever), then the
transaction is aborted. Again, as if it never happened.

This transactional filesystem could be done in a kernel, or in user
space.

Maybe some of the existing journalling filesystems out there already
have interfaces for doing things like this; I'm not up to date in this
area.

The nice thing about this approach is that it's decoupled from CVS;
you can test it quite independently, and use it to add atomicity to
any software that stores data in multiple files whose contents,
properties and directory structure must be kept coherent as a set.

I know that atomicity is not a real problem; basically the only reason
for doing this would be to squash anti-CVS FUD spread by people who
promote other systems. I also realize that without changing some of
the actual algorithms in CVS, such a transactional system would
require lots of temporary space. (Though compression techniques could
help, exploiting the vast similarity between the uncommited material,
and the old material).