Re: [Gnu-arch-users] Re: [forward] open letter to Linus

[Tom Lord]

   From: Andreas Rottmann <address@hidden>

   Tom Lord <address@hidden> writes:

   >   To manage an archive, i use a "dumb-fs" abstraction: you can put
   >   files, make directories, rename things, and delete things.  If one
   >   assumes that rename behaves as in Posix, a dumb-fs database for
   >   imports and changesets can have all the ACID properties of a good
   >   database.   (And, secondarilly, support for composite transactions
   >   in Arch -- committing to many distributed archives at once -- is on
   >   the way! :-)
   >
   This is cool news! Any rough guess when this will land? tla 1.4?


It's not on /my/ plate for immediate attention but it's not a huge 
amount or even a very complicated amount of work if you or someone wants
to give it a try.  I /really/ hope to get to this year, personally, but
patches are welcome.

The gist of what's needed is some changes to the locking mechanism
already used when writing to archives.   Write now, the "next revision lock" 
(the lock that must be held to create the next revision) exists
in one of three states:

        unlocked
        locked
        committed

(each lock is "use once" -- once committed, it is never reused.  A new
lock is created instead.)

What's needed is five states:


        unlocked
        locked
        locked-if-other-revision-X-is-not-yet-committed
        committed-if-other-revision-X-is-also-committed
        committed

If I do N simultaneous commits (single transaction), then all
N locks go into

   locked-if-other-revision-X-is-not-yet-committed

state.   I pick one of the N to serve as X.   Then I move
all the other N-1 locks to state:

        committed-if-other-revision-X-is-also-committed

then I move X to state `committed'.   At leisure -- move
the other N-1 to state `committed' but, as of when X is
committed, they are logically in `committed' state already.

(Thus ends the "database programming 101" informal introduction
to two stage commits :-)

Lock states in Arch are recorded in the filename of the lock
directory.  Additional lock data (such as the identity of the
revision `X') can be stored in that directory.   Adding new
states to the transition diagram for lock mgt. is pretty easy.

The pain-in-the-butt thing that's needed is new features
in `tla archive-fixup' that crawl around and clean-up locks
left in the two new states by failed clients.

-t