[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