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

[Alan Mackenzie]

Hi, Karl,

On Mon, Apr 05, 2010 at 11:32:56AM -0400, Karl Fogel wrote:
> Alan Mackenzie <address@hidden> 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.  ;-)

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

> If you don't typically have multiple different branches going at once,
> then there is no space advantage to Bzr.  (On the other hand, for some
> people there are advantages to having all the history locally, though
> those may not be advantages for you.)

Working-tree + repository > working-tree.  There is NO space advantage in
duplicating the repository over everybody's machines.  It's the
sluggishness which really bothers me.  Is it decompressing which is
taking all this time?  If so, we could do with an option to store in
decompressed format, for those like me who have more disk space than
processing power.

> > bzr log is so slow (40 seconds) as to be only somewhat useful.  

> Hmm.  On my 4-year-old IBM ThinkPad R60 running Debian GNU/Linux:

>   $ time bzr log -n0 --show-ids > log-n0.out
>   real    0m25.147s
>   user    0m23.173s
>   sys     0m1.540s
>   $ 

> That's for the entire history of the project.

It seems the time taken is only weakly dependent on what you're logging
over.  I was just getting logs for a single file,
.../lisp/progmodes/cc-engine.el.

> I don't have a CVS tree handy to test with, but my memory is CVS was
> not faster at that operation -- though of course, CVS had to go over
> the network, so it's hard to compare, really.  What exact log
> operations are slow for you vs the comparable CVS operations?

My impression is that it was faster to open a web browser, get to the
savannah CVS interface and get the log for a particular file starting to
display on the screen than to get the first output from 'bzr log'.  It's
not really the total time that irks, rather the time to start displaying.

> (A non-rhetorical question, by the way.  I believe you when you say
> it's slow, I just want to narrow down what "it" is.)

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.

> >Worst of all is the lack of a proper fine manual; what there is is
> >available only in html or "bzr help", neither of which is properly
> >searchable; what there is is also bloated and vague and generally of
> >low quality.

> ?  http://doc.bazaar.canonical.com/en/ points to plenty of downloadable
> documentation, in HTML, CHM, and PDF formats.

They all lack hyperlinks or are non-searchable.  (BTW, I'll need to find
out what CHM is).  But worst of all is the low quality of the reference
docs.  For example, 'bzr help merge' doesn't say with any specificity
what is being merged or where the result is written.  It talks about
"merging a branch", which makes as much sense as "the difference between
a file" does.  This vagueness is prevalent over much or all of 'bzr help
<cmd>'.  Is it too much to expect these man pages (in effect) to be
precise?

> >Anybody know a mail address to get in touch with the bazaar team?

> Sure: <bazaar {_AT_} lists.ubuntu.com>

Thanks!

> I report bzr bugs at https://bugs.edge.launchpad.net/bzr/+filebug (well,
> I navigate my way there from the Bazaar project home page, but that's
> the page I'm aiming for).  I don't use any "script running in a
> web-browser"; not sure what you're referring to.

I'm referring to that same page.  It doesn't work in my browser.  See my
reply to RMS.

> IMHO it's fine to just describe your bug on that mailing list.

Thanks!

> >So, yes, bzr is wonderful, because it's a DISTRIBUTED VCS, and
> >distributed VCSs are Good Things.  Would somebody please remind me why?

> Well, if you don't like doing the new things that DVCS allows you to do,
> then yeah, there aren't any advantages :-).  For those who like having
> all history locally, being able to make and merge task branches, being
> able to easily push fully-versioned trees to other places, etc, it's
> much better.  I personally would never want to go back.  (I also like
> the truly atomic commits with unambiguous identifying handles, though
> that isn't specific to DVCS of course.)

> But I can certainly see how there are some developers for whom these
> things are not a step forward.

My question wasn't rhetorical.  ;-)  I'd like having local history if I
could access it in less than historical time, and I do appreciate atomic
"commit"s (even though "commit" has had its meaning substantially changed
from CVS).  Then again, I don't know what "push" means in bzr; "update a
mirror of this branch"?  I'm sure I'll solve this puzzle when I put
enough mental effort into it, and how it differs from "merge".

> (Also, some of us like the better sanitation and medicine and education
> and irrigation and public health and roads and a freshwater system and
> baths and public order...)

Indeed!

> -Karl

-- 
Alan Mackenzie (Nuremberg, Germany).