Re: What have the Romans done for us? (Bazaar)

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 6 Apr 2010 14:31:44 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: emacs-devel@gnu.org
> 
> On Mon, Apr 05, 2010 at 11:32:56AM -0400, Karl Fogel wrote:
> > Alan Mackenzie <acm@muc.de> writes:
> > >Would somebody please remind me of all the advantages Bazaar has over
> > >CVS, all the wonderful things it enables one to do.
> 
> This request is still open.  ;-)

See below, for my humble attempt.  First, some responses to specific
issues.

> Working-tree + repository > working-tree.  There is NO space advantage in
> duplicating the repository over everybody's machines.

The advantage is that you can do VCS operations locally.  I mention
some of them below.

I also hope that the disk space is not the issue, nowadays.  (In any
case, we don't replicate the repository, only part of it --
specifically, only the bound branches you have.  All the other
branches are not on your disk.)

> It's the sluggishness which really bothers me.  Is it decompressing
> which is taking all this time?

No.  It's the network traffic.  Fire up some resource monitoring tool
while you are waiting for "bzr up", and you will see that the CPU is
most of the time idle.  If it were decompressing, it would be visible
in the CPU load.

Another data point: when I do "bzr up" on a machine that is on a very
high-speed connection (in the US), it is much, much faster, as fast as
CVS or faster.

> Always the best sort of question.  :-)
> $ time bzr log -n0 --show-ids > /dev/null
> real    1m42.421s
> user    1m36.229s
> sys     0m2.503s
> 
> $ time bzr log -n0 --show-ids lisp/progmodes/cc-engine.el > /dev/null
> real    0m38.924s
> user    0m38.276s
> sys     0m0.538s
> 
> That is so slow it almost transforms an interactive shell into batch
> mode.

"Doctor, it hurts when I do like this". -- "Well, then don't do that."

Don't use the -n0 switch to "bzr log" unless you really, really,
REALLY have to.  The -n0 switch is very expensive.  I think it causes
bzr to read large portion of the branch's meta-data.  If nothing else,
this defeats the advantage of a warm cache -- which I believe was the
point Andreas was making with his comparative timings.

I found that I almost never need to use -n0.  It is only necessary if
you want to look into changes that came from merged branches.  With
the Emacs almost-linear development on the trunk mainline, it is
unnecessary most of the time.  Without -n0, "bzr log" is _much_
faster, and the warm cache does speed it up considerably.

> > >So, yes, bzr is wonderful, because it's a DISTRIBUTED VCS, and
> > >distributed VCSs are Good Things.  Would somebody please remind me why?
> 
> My question wasn't rhetorical.  ;-)

Let me try to give you my answer.  But first, some personal
philosophical digression:

When you begin using a new non-trivial system, you need to learn to
think according to that system's rules, and use the paradigms
appropriate for that system.  If you try to stick to thinking and
paradigms borrowed from some other system, you will most of the time
be disappointed.

To take a trivial example: if you switch to Lisp from C, you should
learn to "think Lisp".  If you keep "thinking C" and write C programs
in Lisp, you will most probably think that Lisp is ``just a slow, slow
replacement for C'', with awkward syntax and annoying misfeatures
(like the fact that symbols have global scope by default), which just
eats up lots of memory.  Sounds familiar?  Observe:

> > >Right at the moment, it just seems like a slow, slow, slow and buggy
> > >replacement for CVS, which consumes several hundred megabytes of my
> > >disk space more than CVS did.  

So don't "think CVS", "think bzr" instead.  Try to find work patterns
that hit less on bzr's disadvantages and instead make good use of its
advantages.  "bzr up" is slow? do it less often, and instead rely on
local commits for your routine development.  After all, who said
everybody and their dog need to see every feature you develop and
every bug you patch right away?

This means do more work in a local branch and less in the trunk.  bzr
favors this pattern; CVS very much defeated it, so you probably didn't
think about using it as a matter of routine.

Other advantages of bzr that should really change the way you think
about your workflow are that you have all the history locally, and
that branching is very cheap.  That means, if you want to see how
something worked or didn't work in some past version, you can have
that in seconds -- something which would take much longer with CVS,
and therefore not hardwired into our CVS-oriented habits.  It also
means that you can have several local branches, one each for every set
of features you develop, yet another branch for testing crazy ideas
and throwing them away (with a single "bzr revert" command), etc. etc.

One thing that remains to be relatively painful is bootstrapping a
fresh branch.  That is the only "fly in the ointment" of "branching is
cheap" idea.  However, on GNU/Linux a bootstrap is still quite fast,
so perhaps this is not a problem for you.  If it is, explore the
co-located branches features in bzr ("bzr switch" etc.).  Me, I just
have several branches bootstrapped in advance, which I can reuse
whenever I need to.  "bzr pull --overwrite" will make any branch a
copy of the current trunk in a matter of seconds, and almost never
require a bootstrap.  Once I have a fresh branch, I can do there
whatever I like.

The fact that switching between different versions is fast and cheap
means that bisecting to find a change that matters should have much
more place in your routine workflow than it ever could with CVS.

Bottom line, instead of trying to bend bzr and keep your CVS-vintage
habits, "think bzr" and change your habits to fit this new tool.  That
is what I did, and although I'm still far from seeing the end of the
journey (and yes, the quality of bzr docs makes it harder), I do see
improvements in the quality of my life as a developer.

HTH