[RFC] branch --bind

[Robert Collins]

In short I don't want to and am not blocking you: community consensus,
if anything, is doing that. I think we can make really good and fast
progress on the UI issues in this area (though its not part of our focus
at the moment) but to do that we need to be looking at the actual issues
we want to fix, not just tweaking local issues. 

On Fri, 2010-01-08 at 18:32 +1000, Ian Clatworthy wrote:
> Robert Collins wrote:
> 
> > 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. 
> 
> Sorry. I simply don't see how simplifying instructions (e.g. those for
> the Emacs developers) from "run branch, then run bind" down to "run
> branch --bind" is increasing surface area and making Bazaar more complex.

The list of options on branch gets longer, the ways to create a bound
branch increase (from 2 to 3).

> >> 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.
> 
> Fix what? Are you saying that bound branches should be removed and that
> everyone should use heavyweight checkouts instead? If so, I can only
> strongly disagree. :-(

heavyweight checkouts == bound branches - it really doesn't matter if
the working tree is in the same .bzr or separate: the behaviour of bzr
is the same. And heavyweight checkouts behave pretty much identically to
lightweight checkouts, with the one issue *I'm* aware of being the
initial data fetch (which over the network is generally not a big deal,
given how much we need to grab to be able to make a working tree
anyway).

So I'm not, and won't, suggest removing bound branches - that would
remove heavyweight checkouts.

Bound branches change many behaviours:
 - branch nick performance goes down the tubes 
 - pull pulls into the master
 - commit does 2-phase
 - tags and other commands probably don't change
When a tree is present there is one more change:
 - update looks at the master

I'm saying we need to fix the overall experience in this area:
 - make many more commands consistent with the changed behaviour
 - or make none of them change (remove the feature entirely, perhaps)

Without tripping on the issue that users expect *the result of*
'checkout' to work fast over the network. Our working tree objects
perform pitifully over the network, and *probably always will*. Stacked
branches aren't usable as a replacement for a full local branch at the
moment (only two bugs to fix, but one is a doozy). Changing from heavy
to light by default will be an overall pessimisation for new users (that
use checkout lp:...), even though an optimisation for users that have a
complex local setup (and thus can have learnt about --lightweight
already). We could make the default over the network heavy, and locally
light, but that might be confusing in its own way.


> In my experience:
> * having 2 types of checkouts with different semantics is *painful*
>   to explain and support

Are you aware of anything beyond these two issues:
 - initial checkout is 'unexpectedly slow'
 - not all commands refer to the master branch consistently in a heavy
checkout.

> * OTOH, bound branches are easy to explain

I dispute that this is a point of difference - they are precisely as
easy to explain as a heavy checkout, because they are the same thing
with the exception of *one* command.

> * the majority of users expect "checkout" to mean working tree ala
>   CVS and SVN. (Even experienced bzr users like Mark and Kiko thought
>   this until recently btw.)

And you get that [modulo the data size] issue. It walks, talks and
quacks. Many of our users use this and *don't know* anything about the
guts - with great happiness, AFAICT. I know this because we get folk
that have heavy checkouts from lp doing stuff happily, and can ease them
into more sophisticated workflows from there. (Still requires an
explanation *at that point*, of course).

> Having said all that, all I want to do *now* is add a single option to
> branch.

Which provoked a long thread, and I don't see consensus here. I can take
some responsibility for this, because I created the update command and
merged John's bound branch prototype in as heavyweight checkouts... but
the issue being contentious is a fact, not something I'm thrusting on
you.

On a purely technical basis I don't see a good reason for the option -
from the CLI, someone doing a very complex setup is much better served
by a custom plugin or larger scale helper than shrinking a single step
out of the whole lot; for the GUI I really don't understand your reasons
- and *anyway* we have a programming API precisely so that we don't need
to make the CLI messy while still meeting the needs of eclipse, qbzr and
other GUI's.

>  You seem to be blocking that because you disagree with the
> longer term direction I'd like to go, i.e. getting rid of heavyweight
> checkouts in good time?

I'm not blocking the qbzr changes you are making at all AFAICT, because
I'm utterly convinced you can safely and efficiently get what you want
by branch + set parent. 

If I saw consensus on this change to the CLI, I would be totally quiet
and be saying 'do it' - but I'm not seeing consensus on this change. I
see some broad themes emerging - that getting rid of the heavyweight
checkout term may be desirable - but thats still different to adding the
option.

It's up to you though: If I wanted to block you I would merge:reject on
the merge proposal, and I don't and won't do that.

I'm a big fan of progressive disclosure in UI's, and bzr branch is
already getting to the point where it discloses nearly everything in one
hit :(

So heres something that has been on my mind for a bit. bind is a special
case of 'please behave specially with respect to <x> remote branch'. And
further, its a single branch command. But we want to get better at
working with groups of branches - and we've got nearly no evolution
happening there.

So here is a strawman that describes a CLI for configuring remote branch
relationships in a 'repo' (in the usual bzr sense of
find-the-containing-repo otherwise use .)

bzr remote --mirror BRANCHSPEC [BRANCHSPEC]
 sets up a mirror of a branch, uses same format, sets a flag or field
somewhere that says 'this branch is a mirror, may not be
committed/uncommitted/pushed to, only ever pulls from the mirror
location' If the target already exists it changes that setting
appropriately

bzr remote --list [URL]
 lists all the bound or mirrored branches at URL or '.'. E.g.
Mirror lp:bzr foo
Bound  lp:bzr trunk

bzr remote --bind BRANCHSPEC [BRANCHSPEC]
 makes the target be bound to branchspec, creating it if needed. Note
that we don't need the following options that branch has;
 -use-existing-dir [just works, different definition]
 -stacked [we know its pointless, user wants to be able to commit here]
 -standalone [intended for use in shared repositories, users can use the
base branch if they want fine grained control]
 -no-tree [because unlike branch this command is about branches not work
areas]
 -switch [ditto]
 -hardlink [ditto]

Is this more work? Yes. Would it be better overall? I don't know: but we
should be talking about this sort of thing. This is the sort of thing
that I really wanted to talk about in Mooloolaba, but we didn't because
its not the main focus for now :(

If we're going to fix this part of the UI (the whole 'how do I get setup
properly' question that this is part of) we need to address the actual
issue that drives the problem: bzr has /no workflow gear around
collections of branches.

-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/a7b5d1eb/attachment.pgp