[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnu-arch-users] [BUG] FEATURE PLAN: two stage commit
From: |
Tom Lord |
Subject: |
[Gnu-arch-users] [BUG] FEATURE PLAN: two stage commit |
Date: |
Mon, 7 Jun 2004 13:22:52 -0700 (PDT) |
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] [BUG] FEATURE PLAN: two stage commit,
Tom Lord <=