[MERGE/RFC] Userdoc Driven Design on the Bazaar 2.0 UI

Neil Martinsen-Burrell nmb at wartburg.edu
Thu Apr 16 18:36:07 BST 2009


Matthew D. Fuller <fullermd <at> over-yonder.net> writes:

> On Wed, Apr 15, 2009 at 05:21:05PM -0700 I heard the voice of
> Maritza Mendez, and lo! it spake thus:
> > 
> > But I spend a lot of time explaining how checkout in bzr is
> > different from checkout in central VCS.  So in this way I agree with
> > Mr. Shuttleworth in that making checkouts light by default [...]
> 
> If you're explaining them in such a way that light checkouts are
> easily explainable, but heavy checkouts get things bogged down, You're
> Doing It Wrong(tm).
> 
> There are ways in which the two behave differently; I'm prepared (in
> fact, quite willing and even eager) to define practically all of them
> as bugs, many springing from heavy's tendancy to try to act like a
> bound branch rather than a checkout[0].  Are you explaining that
> there's a branch underneath, except it's only sorta a branch?  Stop.
> Don't do that.  Talking about unbind, or commit --local?  Stuff a rag
> in your mouth.
> 
> If somebody is ready and able to profit from coloring outside the
> lines by exploiting side effects of heavy checkouts, they understand
> what's going on under the hood well enough to figure it out
> themselves.  If they don't, they aren't.
> 
> A checkout is a checkout.  Ever used CVS?  Just like that.  SVN?  Just
> like that.  The only difference between heavy and light is [should be]
> that one burns a bunch of local disk to cache a bunch of information
> to avoid hitting the network.  That's IT.  That's ALL.  Say that one
> sentence.  Then add the rule of thumb "If the branch is local,
> checkout light.  If the branch is network, checkout heavy.".  You're
> done explaining.
> 
> [0] Really, I've come to think this implementation path was one of our
>     big mistakes.  Having the mechanism for binding branches made it
>     Real Simple(tm) to implement something close enough to a checkout
>     with a local cache to run with.  But having it be a "branch except
>     that" instead of "not a branch except that" just leaves all sorts
>     of trapdoors hanging around that are way too easy to fall into.

While I agree that differences in heavy and lightweight checkouts are bad (and
that referring to them as checkouts with and without a local cache clarifies
this) I don't think that bound branches are the evil you suggest they are. 
Pretending that bound branches are checkouts with local cache *is* harmful.  I
believe that ``bzr commit --local`` is not a good idea and that we should force
users of checkouts to either admit to having a full bound branch (perhaps with
``bzr reconfigure --bound-branch``) in which case they can use ``bzr unbind &&
bzr commit`` followed by a bind and merge at a later date or we should refuse to
commit.

For me, the ability to bind/unbind a branch is one of Bazaar's distinguishing
features as a DVCS.  Not having to remember to ``bzr push`` (which is the wrong
order for data integrity anyways) when working on a local copy of a remote
branch is a strong *benefit* for me.  I've been investigating git recently and
it easily does everything I need, except for making it easy in the UI to
automatically push to a remote branch.  (Yes, one can ``echo "git push" >
.git/hooks/post-commit`` but that is much more fussy than ``bzr bind`` and again
has the wrong ordering for integrity.)

-Neil





More information about the bazaar mailing list