[Top][All Lists]
[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/
>