[RFC] branch --bind

[Martin Pool]

2010/1/9 Ian Clatworthy <ian.clatworthy at canonical.com>:
> Juanma Barranquero wrote:
> 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".

I think if we separate the responsibilities a bit more, some of these
may become more clear.  For instance it may be better, rather than
caching in the wt, to have a specific branch pointing to a specific
repository class that does some caching and that is not writable.

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

Right.

> 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. :-(

Well, we are paying you to move the core tool forward :-}

We need to fix these usability issues and we also need to get better
at resolving questions like this, without it getting into
mutually-assured-discouragement.  This thread is productive but I
think you should still merge the --bind patch as an example of getting
small changes without blocking on the big thing.

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

That's a good list, and I think exposing them orthogonally is good.

It seems to me this still allows both lightweight and heavyweight
checkouts, by either having the working tree separate from the branch,
or by having it colocated with a bound branch.  It's not necessarily a
bad thing that those options fall out, and we could expose things more
cleanly:

  bzr checkout: make a checkout, either on top of an existing
checkout-less branch, or pointing to a separate branch

  bzr branch --bind: make a bound branch and optionally a working tree
(what is now a heavyweight checkout.)

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.

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