Branches without working trees

[Robert Collins]

On Sun, 2005-10-30 at 11:51 -0600, John A Meinel wrote:
> Robert Collins wrote:
> > 
> > Doing it inside Branch gives Branch more responsibilities - we already
> > have trouble with a vague focus in Branch, so I'm being quite aggressive
> > about only adding clearly-Branch-responsibility stuff to Branch.
> 
> Sure. I'm fine having working tree keep itself updated. I suppose a
> small question is whether it should be branch calling working tree, or
> working tree calling branch.
> I still think of a working tree as part of a branch (especially because
> you can have a branch without a working tree, but not the other way
> around, unless you consider a non-controlled tree a working tree.)

I think of a working tree as *having* a branch, not as being *part of* a
branch. Because a working tree always has a branch, but branches *may*
have working trees.


> > Ah. So one of the problems related to this is other folk pulling from
> > the branch.
> > If you have '/foo/bar/branch-format' one day, and
> > '/foo/bar/.bzr/branch-format' the next, then you need to teach Branch
> > that it can connect to '/foo/bar' as the branch in both cases.
> > 
> > Unfortunately, that also means that 'bzr branch /foo/bar/.bzr' will work
> > - and if the branch then switches to the '/foo/bar' layout, the user
> > pulling from /foo/bar/.bzr will suddenly stop working :[.
> 
> I made a comment about this in my changes. I see 2 ways to do it. One,
> just see if the last portion of your path is ".bzr" if it is, then move
> up a step, and consider that to be the true branch root.
> The second is to use a new control file something like
> "without-working-tree". Then when you connect to the branch, you can
> check if this file exists. If it does, then you know you are at the top
> level. If it does not, then move up a level.
> 
> I think this problem very simple to solve.

I would want the new control file I think, as magic path processing is
IMO unreliable.


> > This is an interesting possibility. I'm not sure which way will be
> > clearer for users. Well, perhaps I think that 'branch' should be a DWIM
> > command, and 'pull' should be taught how to create a branch on the fly
> > (bzr pull source new-branch), pull would always work with working trees,
> > and push could (perhaps) never work with them.
> 
> Well, "branch" is a strong term, "get" is a nicer one for this type of
> action. However, "branch" makes it obvious that the local thing is a
> separate entity from the remote one. (ie committing in the local one
> does not commit to the remote one).

I think 'get' should be something tied into activating the cvs-like mode
we've discussed.

> In my head, pull is usually a fast operation, because it only pulls a
> few things, while branch takes a long time, because it has to grab
> everything.
> I was very surprised when I did "pull --overwrite" in the wrong
> directory and it started pulling 2k changes. I would have preferred it
> to fail. (Though it might have been my fault for having a bogus tree
> lying around).

:)

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/20051030/29b3c71a/attachment.pgp