[RFC] branch --bind

[Scott Aubrey]

FWIW, I completely agree with Ian

One thing that I came across UI that totally did not make sense was checkouts are bound branches. So, armed with this knowledge I tried creating my setup, which involved bound, treeless branches under a shared repository. Easy:

bzr init-repo repo
cd repo
bzr co bzr+ssh://remoteserver/path/trunk trunk

Because heavyweight checkouts are the same as bound branches right? NOPE. 

bzr co is conceptually "checking out" a working tree, so requesting a checkout understandably created a working tree with the branch too, despite the --no-trees on the repo.

so... The next logical thing to do after figuring out this, is to "bzr branch --bind": not implemented. Doh!

Next? ... two step "bzr branch", "bzr bind":  "bzr: ERROR: No location supplied and no previous location known".

These terminologies just don't work, and that fact that you can "bzr co" is treeless branch to just create a WT confuses it even more.

Short term, I think bzr bind need to choose parent automatically if no previous bind location. It just makes sense.

long term, IMHO, "bzr co" needs to deal with creating WT *ONLY*. Anything else is just confusing. so My vote is with making "bzr co"  lightweight by default.

- Scott

On 8 Jan 2010, at 09:29, Robert Collins wrote:

> 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