[RFC] branch --bind

[Martin Pool]

2010/1/5 Jelmer Vernooij <jelmer at samba.org>:
> On Tue, 2010-01-05 at 10:51 +1000, Ian Clatworthy wrote:
>> I've put together a patch extending the branch command with a --bind
>> option. See
>> https://code.edge.launchpad.net/~ian-clatworthy/bzr/branch-bind-option/+merge/16725.
>> The intent is that
>>
>>   branch --bind X Y
>>
>> is equivalent to
>>
>>   branch X Y
>>   cd Y
>>   bind X
>>   cd -
>>
>> Poolie has approved this patch. lifeless and fullermd have asked for
>> more discussion before this lands. Some background ...
>>
>> FWIW, my short term driver for this is a better qbranch dialog. Due to
>> locking considerations, I can't easily add a "Bind to parent" checkbox
>> to qbranch without pushing the functionality down into the bzr core.
>>
>> Longer term, I think our "checkout" model is broken - heavyweight and
>> lightweight checkouts have different semantics - and needs fixing. I'd
>> like to see lightweight checkouts the default with the option of a true
>> (history horizon) cache. That's a separate debate though. If anything,
>> having "branch --bind" is good because we can introduce new users to
>> bound branches without needing to explain all the complexity/issues
>> around various checkout types.
> +1
>
> I like the term "bound branch" much better than checkout:
>
>  * checkout is associated historically with working copies in
> Subversion / CVS; for git users it means switching branch
>  * the name "bound branch" is self-explanatory
>
> Regardless of what meaning we end up giving to "bzr checkout", I think
> this is a good change and the clearest name available for the particular
> configuration that currently goes by the name "heavyweight checkout".

I think I'm agreeing in saying:

To me a checkout should be just a working tree, whose branch is
located elsewhere.  It has wt parent revisions (typically one, or more
if there is a merge).  Any operation that looks at the branch or
repository will of course need to open them.

A bound branch is one where commits are synchronous with pushing to
the master branch.  It is just a branch so you can have a tree
colocated, elsewere, or not present at all.

The place where this gets complex, I think, is when people want to
consider temporarily disconnected operation, or operation over a slow
network.  A separated checkout is clearly useful just locally, but a
bound branch apparently not.

So why would you want a bound branch locally rather than just a checkout?
1- so you can do readonly operations on the branch and repository,
like log, or diff against historical revisions, without connecting to
the master branch
2- so that you can commit locally, intentionally diverging the bound
branch from its master.  This adds a new mode for disconnected
operation and I question whether it is worth having the complexity
when people could just use a new branch.

-- 
Martin <http://launchpad.net/~mbp/>