[RFC] branch --bind

[Robert Collins]

On Mon, 2010-01-11 at 15:31 +1100, Martin Pool wrote:
> 
> 
> So does this take Robert's points into account, or what problems would
> they point to?  I think mostly that he thinks people who want a local
> copy in sync with a remote branch really need more than just a
> checkout, therefore changing 'bzr checkout' to do only that is likely
> to lead them into trouble. 

Short version: I think the thread is fundamentally confusing, with lots
of long descriptions but no really clear set of /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.

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.

Aaron has in the past objected to changing bind to bind to the parent by
default, and this proposal seems to suffer the same issues.

Matthew Fuller has objected in the past to things that make heavyweight
checkouts less clearly different to branches - and in this thread
objected to the new parameter while the putative differences between
bound branches and heavyweight checkouts are not resolved.

It was because I knew of these other peoples concerns that I raised the
concept of this new parameter needing discussion.

My own concerns are merely that it seems like a CISC style thing,
another option people need to know about, rather than a clearing up of
what confusion there is. I don't think thats enough to block it - and as
I said, I wouldn't block this anyway; we do need to experiment. I really
still don't see that the issues this discussion has ended up centred on
are helped (or hindered) by the change.

I do have some real serious concerns about some of the proposals put
forward - for instance a 'bound branch' whose /only/ change from a
normal branch is a lockstep commit. I think that would be surprising:
'binding' of two objects together implies at least some degree of
coherency, and commit is just one of many operations that could split
things apart. uncommmit, push, pull, update[as it is today], commit,
tag, [others?]: these are all commands that mutate the branch - and why
would a user expect one to change the master and not a different one?

As you say, rather than a branch reference we could use a caching branch
(e.g. a bound, stacked branch with a data-caching policy) by default in
'checkout' - I'd love to see that, and would support that as a better
default than a bound unstacked branch. I see a significant performance
risk if this is done without serious perf testing though. Doing caching
inside the working tree would be a terrible mistake design wise: we've
been there and still feel pain from that decision.

We currently have three orthogonal concepts: branch, tree, repository:
heavyweight checkouts are /implemented as/ 'branch[bound] + tree' - and
while we can make those separate concepts be more clearly discussed,
perhaps that isn't actually the issue?

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

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.

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