Bound branch implementation

[Jan Hudec]

On Mon, Nov 14, 2005 at 14:38:58 +0100, Harald Meland wrote:
> [Nathaniel McCallum]
> 
> > On Sun, 2005-11-13 at 15:03 -0600, John A Meinel wrote:
> >> I am happy to hear alternative possibilities. But the above work flow
> >> is
> >> very difficult to scale above a 1-1 relationship, since you have the
> >> problem Erik mentioned, where a commit into one branch, needs to
> >> successfully commit into multiple other branches. We can always add
> >> 2-phase commit, but it seems to be unnecessary overhead at this
> >> point. 
> > The first stage of a --sync'd commit is merging in all remote branches.
> > That is where it would fail.
> 
> No, not necessarily; without a two-phase commit, sync-merging with
> more than one shadow would introduce a race condition.
> 
> Imagine developers A and B who both tries to update shadows X and Y,
> which are at revno 42.
> 
>   A <- X at 42
>   A -> X    # Creates 43a
>   B <- Y at 42
>   B -> Y    # Creates 43b
>   A -> Y    # Wants to create 43a, but 43b is already present.

There is a problem even with a two-phase commit. If the client looses
connection during the transaction, it can't be cleaned up. And the
client may be gone for long and the user may not even be interested in
trying to complete the transaction by then.

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.

--
						 Jan 'Bulb' Hudec <bulb at ucw.cz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051114/89c9d36a/attachment.pgp