Bound branch implementation

Jan Hudec bulb at ucw.cz
Wed Nov 16 08:00:46 GMT 2005


On Tue, Nov 15, 2005 at 20:56:22 -0500, James Blackwell wrote:
> On Tue, Nov 15, 2005 at 08:47:45AM +0100, Jan Hudec wrote:
> > 
> > I'd even like to see if you could have a chain of bound branches. Branch
> > A on server somewhere far, branch B locally in the office, bound to A
> > and branch C on work station, bound to B. Though of course commit always
> > needs to go down all the way to A.
> 
> With single layer binding the client can know that it needs to update
> either just itself, or another branch and then itself. With multi-layer
> binding the client then has to engage in a game of scavanger hunt.... it
> wants to update here, but it needs to update there. It wants to update
> there, but it has to update the another there.

Commit to bound branch is commit to master and pull. The multi-level
just falls out naturally from the recursive nature of bound commit.

> Now, instead of performing one commit (or two with a simply bound branch),
> you're now performing three, four or more commits all at the same time.

There is really just one commit. The others are pulls.

> As with any chain, it would only be as strong as the weakest link. If one
> of those intermediate branches were unreachable, then you'll have an
> inconstant state that you'd have to chase at several locations. 

No. If it fails, the ultimate master either has the transaction
commited, or rolled back as for any other commit. The bound branches may
at most remain not up-to-date, which update should fix (update needs a
recursive flag for this (which should NOT be default imho, since that
would beat any benefits of chaining)).

--
						 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/20051116/31ce0aef/attachment.pgp 


More information about the bazaar mailing list