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

[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






reply via email to

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