Bound branches revisited

[Jan Hudec]

On Tue, Dec 13, 2005 at 14:01:37 -0600, John Arbash Meinel wrote:
> I want to re-open the discussion about bound branches, since I would
> like to implement them soon.
> 
> I know it was discussed that doing a commit to a bound branch would do
> the remote commit, and then just do a pull to the local system. I agree
> that there are some nice properties. If the commit fails after
> committing, but before pulling, you just 'bzr pull' and you are up to date.
> 
> It means that the commit will be slower. Rob mentioned that you could
> pull information out of the local filesystem, but I don't think you can.
> Because the weaves aren't necessarily perfectly in sync. (Think failed
> merges, failed commits, shared weaves, etc).
> It would be nice if you didn't have to download the remote weave, update
> it, push it back up, and then download it again to update your local files.

You don't need to download it the second time, because you can keep the
version you upload around. Of course it's still an optimization that
will wait after it works.

> I believe with knits, because we don't mesh things together, we can
> compute the commit with just the ancestry, so we do know that the local
> and remote knits at least contain that much information.
> I would like to see bound branches before we see knits, though. Since I
> don't know how long it will be before knits are perfected.
> 
> So as a first implementation, which can be optimized later. I would just
> say that WorkingTree.commit() ends up checking for a bound branch, and
> if it exists, it uses that as it's commit branch, and then updates the
> local one afterwards.
> 
> As an interface issue, how do we handle 'bzr pull'. I think Robert
> mentioned that it probably should use the bound location's parent as the
> default pull target. And then you can use 'bzr update' to update versus
> your bound branch. The problem is that you can update a checkout of a
> bound branch.
> There are a couple of things that can happen, but imagine this:
> 
> mainline-branch
> 	Publicly accessible, no working tree, (inside a repository?)
> jam-dev-branch
> 	Publicly accessible, no working tree, has mainline as default
>         parent
> jam-laptop-branch
> 	Private, bound against jam-dev-branch, no working tree (inside
> 	repository on the laptop)
> jam-working-tree
> 	Points to jam-laptop-branch
> jam-working-tree2
> 	I forgot about my other working tree, also points to
>         jam-laptop-branch
> jam-desktop-branch
> 	On my desktop, I have a standalone branch, which is bound to
> 	jam-dev-branch (and has a working tree).
> 	
> 
> With this setup, I want to be able to edit inside jam-working-tree, and
> when I commit, I want it to update the public jam-dev-branch, and the
> local jam-laptop-branch. I need a way to update jam-desktop, so that it
> is up-to-date against it's bound parent.
> 
> I go to jam-desktop and commit, which means my laptop-branch is now out
> of date. I need a way to get it up-to-date. I also need a way that when
> I recognize that my second working tree is also out of date, I can
> update it.
> 
> Here is one possibility:
> 
> cd $jam-working-tree
> bzr pull
> 	Reads the working tree in $jam-working-tree
> 	Sees that the branch is $jam-laptop-branch, which is bound to
> 		$jam-dev-branch
> 	Connects to $jam-dev-branch and sees that $mainline-branch is
> 		the parent location.
> 	Connects to $mainline-branch, and pulls the changes into
> 		$jam-dev-branch
> 	Pulls the changes into $jam-laptop-branch
> 	Updates $jam-working-tree
> 
> cd $jam-working-tree
> bzr update
> 	Reads the working tree in $jam-working-tree
> 	Sees that the branch is $jam-laptop-branch, which is bound to
> 		$jam-dev-branch
> 	Connects to $jam-dev-branch and pulls any new changes into
> 		$jam-laptop-branch
> 	Updates the working tree
> 
> With the above situation, there is no way to update jam-working-tree2,
> to just what exists in jam-laptop-branch, since it will always try to
> connect to jam-dev-branch and pull changes first.

I believe that's correct. Bound branch should behave as a local
write-back cache.

> The alternative is:
> 
> cd $jam-working-tree
> bzr pull
> 	Reads the working tree in $jam-working-tree
> 	Sees that the branch is $jam-laptop-branch, which is bound to
> 		$jam-dev-branch
> 	Connects to $jam-dev-branch, and pulls the changes into
> 		$jam-laptop-branch
> 	Updates $jam-working-tree
> 
> cd $jam-working-tree
> bzr update
> 	Reads the working tree in $jam-working-tree
> 	Sees that the branch is $jam-laptop-branch
> 	Updates the working tree
> 
> Now, what do people think about the default behavior. If I am in a
> checkout, and I'm bound, should "bzr update" do the full update, or just
> against the local branch.
> I think the full update would be nice, as long as it can fall back to a
> local update without having to unbind. (otherwise there is no way to
> update my local checkout when I'm on an airplane)

When connection to the bond parent fails, update should warn about it
and continue with updating the checkout. It can have an option not to
try to connect for the case when user knows it's unreachable (eg. on the
plane).

-- 
						 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/20051214/f808469c/attachment.pgp