Re: base

[Stephen J. Turnbull]

Eli Zaretskii writes:
 > > From: Miles Bader <address@hidden> Date: Wed, 25 Aug 2010 09:19:37
 > > +0900
 > > 
 > > I think it's related to bzr being inconsistent, complicated, and
 > > confusing,

Yep.  bzr violates about half the maxims in The Zen of Python (aka
"python -m this").  That's not a crime, exactly, but it's indicative.

 > > with no simple mental model for users to latch onto,
 > > and multiple operating modes poorly stitched together (it's not
 > > really clear what bzr wants to be; sometimes it seems like its
 > > trying to be everything at once -- and, predictably, failing at
 > > all as a result).
 > 
 > I think you simply don't like bzr, so you are inventing imaginary
 > problems that are present in it, but absent in other dVCSs.

No.  Miles exaggerates; some of the things bzr tries to do it does
quite well.  But the lack of a teachable mental model is a real
problem, regularly visible on the bazaar list.  People who like bzr a
lot rarely have any idea how it works; they just happen to have
workflows that fit well with a short list of bzr commands.  That's
nice, of course, but it is *not* easy to figure out, or explain, how
to do the occasional things that don't fit one of those workflows.

And it shows up in the bugs and problems that are posted to the bazaar
list.  Eg, I have never seen a wedged git or hg repository or branch;
it is *always* possible to get back to where you started from (unless
the content storage itself is corrupted).  The worst that can ever
happen (unless you explicitly type "git commit" to make the mess
permanent) is that you've wasted hours trying to resolve an insane
merge conflict.  But people post regularly (recently, I'd say about
once a month) asking how to get some previous version (in some cases,
any version at all) checked out of their bzr branch.  And in some
cases the answers are very non-trivial (writing a plugin for bzr that
replaces buggy functionality, for example).

These are bugs, of course, but they're unimaginable in git or hg,
because the history data is wedged, not the content storage.  With the
history data used by git, at least, wedging the history would be as
criminal as wedging a list in Emacs LISP would be.  But wedged history
*is* occasionally reported for bazaar.