[RFC] branch --bind

[Scott Aubrey]

Also, forgot to add to the short term list that I'm in favour of adding --bind to branch too, for the same reason as setting bzr bind to use parent if no previous bind location is specified.

On 8 Jan 2010, at 09:51, Scott Aubrey wrote:

> 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
>