[RFC] branch --bind

[Ian Clatworthy]

Juanma Barranquero wrote:
> On Sat, Jan 9, 2010 at 00:46, Matthew D. Fuller
> <fullermd at over-yonder.net> wrote:
> 
>>> In this thread, it has been said that
>> Yes and no; very different things have been said.
> 
> Well, yes, of course. I wasn't summarizing 47 messages in ten lines.
> 
>> This is what the terms mean in terms of what bzr does now.
>> This is what the terms mean conceptually.
>> This is my hand-waving subdivision of how the current behavior
>> compares to ideals.
> 
> Though I am grateful for your answer, I'm not even a bit closer to
> understanding exactly what you Bazaar developers consider a
> "heavyweight checkout", a "bound branch", and their differences.

Let me have a go at explaining things (from my biased perspective) ...

1. A "bound branch" is a (typically local) branch which is associated
with another (typically remote) "master" branch so that a commit to the
local branch also commits to the master branch. Furthermore, the commit
is intelligent: it won't happen in either location if the master branch
is out of sync with the local one. From *my* perspective, nothing else
should be special about a bound branch vs a normal branch.

2. Conceptually, a "checkout" is a working tree associated with another
branch and all actions on the checkout affect the associated branch.

Bound branches are great for maintaining a local mirror/trunk of an
upstream. Checkouts are great when you want to share a working tree
across multiple branches. They are also useful if you don't want full
history locally, just the latest code.

So far, so good I hope.

Now the messy bit. We have 2 types of checkouts:

* lightweight - just a working tree (like CVS and Subversion)
* heavyweight - a working tree and a bound branch colocated.

By maintaining a "local branch" behind the scenes, heavyweight checkouts
perform faster than lightweight checkouts when the associated (master)
branch is remote. The problem is that heavyweight checkouts, IMO, screw
things up on multiple levels.

Matthew is absolutely right: we have 75% bound branches and 25%
heavyweight checkouts. Both are partly broken. Here are some examples
where BB is a branch created using 'bzr branch' then 'bzr bind', HC is a
heavyweight checkout created using 'bzr checkout' and LC is a
lightweight checkout created using 'bzr checkout --lightweight'.

A. 'bzr info BB' says it's a checkout. It's not.
B. 'bzr log BB' accesses the master branch unnecessarily.
C. Ditto 'bzr nick BB'.
D. LC can have BB as its master branch; HC can't.
E. 'bzr switch LC' associates the working tree with another branch while
   'bzr switch HC' associates the underlying bound branch with another
   master.
F. 'bzr unbind' works on a HC but not an LC.

The friction comes about because heavyweight checkouts were implemented
using a bound branch. IMO, they shouldn't have been. It's absolutely
fine to have a branch cache under a checkout (ideally with a
configurable history horizon) but that cache shouldn't ever affect
semantics, only performance. Likewise, bound branches shouldn't have
been made more complicated than "ensure lockstep commits".

Implementation details and bugs aside, the biggest problem is that
Bazaar has both bound branches and heavyweight checkouts while no other
DVCS has either. It confuses users having to choose and every new
project moving to Bazaar needs to go through this (IMO) unnecessary
learning curve of understanding the differences between bound branches
and heavyweight checkouts.

The root problem is that fixing this isn't our priority right now so we
lack the courage/time to fix it. Even minor improvements (like my branch
--bind patch which took 2 hours to put together on my holidays)
degenerate into long mailing list threads that absorb man weeks of
energy. I think I'll go back to improving the GUI on weekends and forget
about trying to move the core cli tool forward. :-(

Personally, I'd like to have 3 core concepts only:

1. Repository
2. Branch
3. Checkout (aka Working Tree).

Users should then to able to:

* Make a repository treeless or not.
* Make a branch bound or not.
* Give a checkout a cache or not.

That's flexible, easy to explain and clean. Importantly, each concept is
orthogonal and adds value in it's own right.

HTH,
Ian C.