Bound branch implementation

[Harald Meland]

[Jan Hudec]

> Thus I'd suggest to force a chain of shadows, ie. instead of X and Y
> being shadows of Z, X would be shadow of Y, which would in turn be
> shadow of Z. Then the transaction would succeed if it succeeded on X
> and Y and Z would simply look at the state of X and resolve the
> transaction accordingly.

How would you handle loops in shadow chains, e.g.

Developer A adds shadow from U -> Y, and Y -> Z
Developer B adds shadow from V -> Z, and Z -> Y

resulting in this shadow graph:

           ___
          /   v
  U ---> Y    Z <--- V
         ^___/

If loop resolution is implemented as "chain stops at previous node
when visiting node N for the second time", you'd still risk races:

A gets shadow chain U -> Y -> Z, while B gets V -> Z -> Y.  Both A and
B runs "bzr commit" simultaneously, and things happen in this order:

  A commits local changes in U to Z (as revno 43a)
  B commits local changes in V to Y (as revno 43b)
  A wants to update the next part of the shadow chain, Y, with 43a,
  but 43b is already present.

I guess a "when loop is detected, refuse to perform a commit" rule
could work, but I don't think it would be an optimal solution as seen
from the point of view of an "I just want to commit" user.

Are there other options?
-- 
Harald