[RFC] branch --bind

[Robert Collins]

On Fri, 2010-01-08 at 17:25 +1000, Ian Clatworthy wrote:

You could call 'bzr bind' very safely immediately after branching, or
use the API to set the branch parent directly after doing a heavyweight
checkout.

> > I didn't see the same consensus you seem to:  bound branches
> remaining
> > is totally different to this being a good UI change. I will take
> this
> > point to chime in and say that I really do think this makes the bzr
> UI
> > harder to explain and more likely to confuse people.
> 
> You'll need to explain why you think that. How does replacing 2
> commands
> with one makes the UI more confusing exactly?

This is a bit of an odd question anyway: you're not replacing two
commands with one. You're add an option to one command so that you don't
need to use two to achieve the same task... but the other command is
remaining in place. We start with two commands and end with two.

That said it makes the surface area larger and thus more explaining is
needed. In this very debate the --lightweight option to checkout is an
example of this very issue. 

> Bound branches are a simple concept: a commit to the local branch also
> gets committed to the master branch. That's dead easy to explain,
> particularly to anyone familar with central VCS tools.

They are a concept that we regularly have to explain to people on IRC
and this list. I don't have hard stats, but it turns up a lot, which is
why we have to fix it.

> > Users making a new branch are *really* unlikely to want it bound,
> unless
> > they actually want a checkout.
> 
> That's not true. It's perfectly reasonable to have a bound branch
> where
> the local branch is treeless. If you want to emulate colocated
> branches
> using a lightweight checkout today, that's perfectly reasonable.

Sorry, I don't follow there. I *do* ack the desire to have a treeless
bound branch sometimes - I used that myself in squid3's recommended
developer layout. I don't see what colocated branches has to do with
this, unless you're using that as a particular case of why you might
want a number of treeless branches.

> > Setting the parent location for a bound
> > branch to the master location is a bad idea as well, because
> commands
> > like 'pull' become less useful.
> 
> Again I disagree. pull on a bound branch works fine - I do it several
> times a day. pull on a checkout is currently less convenient btw (the
> checkout command doesn't remember the parent location).

In the following conditions:
B bound to A, B.parent == A
C bound to A

You should always use 'update' - it knows how to preserve the left hand
status of A's parents in the working tree when history has forked.

Pulling in a bound branch where B.parent != B.master works well, of
course - I wasn't talking about that case though.

-Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20100108/4dd1885d/attachment.pgp