Bound branch implementation

[Robert Collins]

On Mon, 2005-11-14 at 16:29 -0600, John A Meinel wrote:
... 
> > The more I think about it, the more I feel that 
> > $ bzr pull
> > in a bound branch should pull from the location of parent in the
> > bound-to branch, and we should be using 
> > $ bzr update
> > for both checkouts and bound branches to 'get stuff from the centralised
> > branch'.
> > 
> 
> I've started working on this, because I sort of agree with you. The
> problem is that you can bind the branch a checkout points to.

Well. Interesting you should mention this, I just had a discussion with
Martin about making some of these behaviours more regular, easier to
describe and so on.

> So if you do:
> 
> branch B1 # The published branch in a centralized location
> branch B2 # The branch in my local archive, so I can work offline
> checkout C1 # My local checkout of B2
> checkout C2 # Another checkout for some reason
> If there is a change introduced by C1, you need a way to let C2 know
> about it. At the same time, if there is a change introduced into B1, you
> need to pull that into B2, and then updated both C1 and C2.
> Otherwise I was thinking about using the heuristic for 'bzr pull' that
> if bound_loc == parent, then use bound_loc's parent.


One way of thinking about 'checkouts' and 'bound branches' is that they
are workflow tools, built on the basis of 'Branch' and 'WorkingTree'
objects. When using either bound branches or checkouts, one cares
primarily about the working tree locally, and about the 'history' that
many people can see remotely. I think that if we add a flag to branch to
indicate its having a working tree or not - rather than a heuristic from
the protocol - we can make some of these behaviours easier to predict,
at the cost of a little less flexibility.

So heres the proposal, in a nutshell:
Binding to a branch, and checking out from a branch, will require that
the branch have no working tree. In the immediate future, push will give
an error when pushing to a branch that is marked as having a working
tree (unless it can successfully construct one), in the medium term it
could splat the diff down across the wire. Branches without a working
tree will put their history in the root, not in root/.bzr. Branch.open
will look for both 'branch-format' + 'no-working-tree' and
'.bzr/branch-format' accordingly.

This has some very nice properties:
It reconciles the issue where putting the branch history in the root
could lead to confused clients when the branch was given a tree - the
explicit marker in the tree will ensure that the correct url is recorded
always.
Archive branches are no longer special cased to have no working trees -
its just a normal working-tree-less branch in that respect.
Its easier to describe how checkouts + bound branches + standalone
branches interact:
'There are two kinds of branches, standalone branches which have a
working copy of the source code, and shared-branches which contain just
the history, and you do a checkout or a 'bind' to get a working copy of
the code.'
'bzr update' becomes clearly what you use to update a bound or checked
out tree against its shared location. bzr update in a standalone branch
will give an error.
'bzr pull' operates from the shared locations metadata in bound branches
or checkouts.


Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051115/a6f6841d/attachment.pgp