Bound branch implementation

[John A Meinel]

Robert Collins wrote:
> 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.

I think your idea is generally okay, but I think you are overlooking my
preferred use case.

I publish an archive on my server. I make a bound copy of that archive
on my laptop. And I create a checkout from my laptop archive, into my
working directory.

This gives me locally shared storage, so I don't take a lot of space on
my laptop, it allows me to work offline if I need to, and it generally
keeps things published on my server.

This means that I have a checkout of a bound branch. So I need a command
to handle the checkout, and one to handle the branch.

Now, you could argue that if I updated one, I'm going to update the
other. And I can agree that I don't see much utility in saying "update
the branch, but not the checkout".
But there are 3 objects in this system, the local checkout, the local
branch, and the remote branch.

John
=:->

> 
> 
> Rob
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051114/7cc39707/attachment.pgp