gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] [BUG] FEATURE PLAN: two stage commit


From: Bug Goo
Subject: Re: [Gnu-arch-users] [BUG] FEATURE PLAN: two stage commit
Date: Wed, 16 Jun 2004 16:40:03 +0000

Created as bug 150

On Mon Jun  7 20:19:16 2004, Tom Lord wrote:
> 
> 
> This will enable "distributed commit" -- a simultaneous, atomic commit
> to multiple branches (possibly in separate archives) at once.
> There are two ways (at least) to do it and I'm not sure which is best.
> 
> 
> * Extend the "dumb server" archive protocol
> 
>   Clients should be able to "almost commit" a revision by
>   renaming it to something like:
> 
>     patch-<N>--<secret>--<other-revision>--<other-archive>
> 
>   instead of just "patch-<N>".
> 
>   Such a "half-committed" revision should act just like a 
>   held lock.
> 
>   The lock-breaking algorithm has to be modified.   Asked to
>   break a half-committed revision, it _must_ ensure (creating
>   if necessary) the existence of the revision:
> 
>      <other-archive>/<other-revision>
> 
>   If that revision contains a header of the form:
> 
>       Two-stage-commit: <secret>
> 
>   then the lock can not be broken but instead may as well
>   be renamed to just:
> 
>       patch-<N>
> 
>   Otherwise (if the other-revision doesn't have that log header),
>   then the lock _is_ broken and the half-committed revision 
>   directory can be deleted at will.
> 
> 
> * Allow conditional changesets
> 
>   Replace the changeset part of a revision with a list of changesets,
>   each preceeded by a condition.
> 
>   For example, a revision might be defined by the rule:
> 
> 
>       if foo--1.0--patch-34 has the log header "Foo: bar" then
>         changeset is A
>       else
>         changeset is B
>       fi
> 
>   For a simple two-stage commit, A can be the changeset to apply if
>   my full txn succeeds, B can be a null-changeset indicating a 
>   failed txn.
> 
>   The full generality of being able to express arbitrary conditionals
>   might be useful or might not.   It might be ok to only permit
>   conditionals of the specific form illustrated above --- just enough 
>   to support two-stage commit.
> 
> 
> Either way, we gain the ability to commit changes to multiple branches
> atomically.   But there's a new problem: these meta-commits lack
> names.  We can't even begin to conceive of commands that would merge a
> multi-project commit unless there's some name by which we can refer to
> that commit.
> 
> A minimalist solution to that is to use the name of the last revision
> in a two-stage commit, the one that has the "Two-stage-commit:"
> header, as the name for composite commit.   It can have extra headers
> to say which other revisions were created in the same commit.
> 
> -t
> 
> 
> 
> 
> _______________________________________________
> Gnu-arch-users mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnu-arch-users
> 
> GNU arch home page:
> http://savannah.gnu.org/projects/gnu-arch/
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]