[RFC] branch --bind

Martin Pool mbp at canonical.com
Mon Jan 11 08:04:35 GMT 2010


2010/1/11 Robert Collins <robertc at robertcollins.net>:

> Short version: I think the thread is fundamentally confusing, with lots
> of long descriptions but no really clear set of /bugs/.

I think I know what you mean, but "Bugs" (meaning items in the bug
tracker) may not help so much as a clear identification here of what's
desired and what's problematic.  There probably are some bugs like "X
is confusing" but that's not a very good format for analysis.  Bugs
per se are better when they can at least in principle be solved in
isolation.  I see you get to that later in your mail so it's all good,
but let's not have people running off to turn them all into bugs.

> My issues with a proposal to make 'checkout' of a network URL create a
> branch reference by default are that it will suck. This is an assertion
> that I'd love to see disproved - with data to help me understand where
> it doesn't suck.
>
> Such a proposal seems to be a core element of fixing the apparent UI
> issues in this space - 'doing this will fix the UI confusion we have'
> has been put forward before. I don't disagree that it will reduce
> confusion by being somewhat more close to the behaviour of other
> systems, but confusion is better than terrible performance by default.

That comparison is like a division by zero.  :-)  Both options are bad
and uncharacterized, and in either case we would hope to improve
things, so you can hardly choose.

If you have a wt referring to a branch on the network, anything that
looks at the branch or repository will go across the network.
Furthermore, they'll probably access it in a network-naive way,
because those paths have been optimized for local access.  Is this
inherently irredeemably bad?  It seems at least plausible that there
are people with sufficiently fast connections relative to their tree
size that accessing the branch over the network is not bad.

One could have a big red warning if you do try to checkout across the
network, suggesting you branch instead.

> Now for the particular --bind option to branch - I don't have an issue
> with it per se; I prompted this thread because getting a bound branch
> with parent==master seems to muddy the waters of a muddy topic.

I actually want to use this issue as practice at picking out the small
good steps we can take.  --bind is not totally certain to be a good
thing, perhaps, but it has substantial support and it can't be that
bad.

> Perhaps the issue is threefold:
>  - bound branches are the only offering for a particular feature 'lock
> step commit'
>  - they also [wrongly?] check they are synchronised very frequently
>  - some commands, switch in particular, have ambiguous definitions when
>   a bound branch *and* a branch reference are in use.
>
> Users that really only want 'lock step commit', get a whole lot more
> than they bargained for, including performance hits. Users that want to
> work on a remote branch get a good experience with 'checkout' (modulo
> initial branch time, see under bound stacked) but they are perhaps a
> small % of users?

I think we need to go back to an earlier step than a list of bugs and
get the use cases for these operations, and off the top of my head
they are:

 * I want a readonly reference copy of a remote branch.  (For example,
I want to just look at the source of a project, or I have a checkout
on a web server to publish the tree.)  I want it to use little disk
space, and I want the initial checkout and later updates to be
reasonably fast.

 * I want a mirror of another branch, so I can look at it or merge it
offline.  I'd prefer that I actually can't accidentally modify it.

 * I want to be able to manipulate a branch whose canonical location
is elsewhere, by having a working tree into which I can merge or in
which I can make other changes.  Those changes should update it in
lockstep.

 * I want to closely collaborate with other developers on a single
conceptual branch: we should never explicitly have to merge, we just
update and commit like in cvs.

 * I want all my branches mirrored off my laptop as soon as I commit,
so that no data can be lost if it's stolen.

>
> I'd like us to get a list of bugs with the current setup out of this
> thread. Here is my strawman list (these are all bugs I agree with btw):
>
>  * bound & lightweight checkouts together lead to confusion (which thing
> will 'bzr switch' alter - the lightweight branch reference, or the bound
> branch master pointer.)
>
>  * bound branches talk to the network much more often than was
> originally intended or desired.
>
>  * checkout by default downloads a lot of data that the user may not
> have been expecting.
>
>  * The hidden branch a default checkout creates can cause confusion
> until users understand what a bound branch is and how that combines with
> their tree to get something that operates like a CVS checkout - commits
> going to the master.
>
>  * lockstep-tip-changes are not possible except via bound branches
> (other use cases include nested tree commits, multi-master branch setups
> for distributed organisations with low-latency disaster-recovery needs)

* diverged bound branches make merges etc more complex, therefore both
confusing people and

> Finally, I think its because we haven't agreed on the /direction/ that
> little changes like this are contentious: we can't all see that it *is*
> an incremental improvement, so of course we argue.

Probably; on the other hand there is something to be said for at least
taking small steps and seeing if they are _actually_ an improvement,
if the change is not irrevocable.

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



More information about the bazaar mailing list