What have the Romans done for us? (Bazaar)

What have the Romans done for us? (Bazaar)

[Alan Mackenzie]

Hi, Emacs,

Would somebody please remind me of all the advantages Bazaar has over
CVS, all the wonderful things it enables one to do.

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.  There doesn't seem to be a bzr equivalent of
http://cvs.savannah.gnu.org/viewcv; bzr log is so slow (40 seconds) as
to be only somewhat useful.  Even updating one's repository takes many
minutes, something which took only a few seconds with CVS.  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.

At Stefan's suggestion, I tried

  $ bzr diff -r tag:EMACS_23_1 lisp/progmodes/cc-*.el

.  This crashes bzr.  I've just updated to the latest version of bzr
(2.1.0), and it still crashes.  So keen are bzr's developers to get
decent bug reports that they make you register (on "launchpad") before
they'll deign to permit you to submit one.  They insist on you
submitting this bug report via a script running in a web-browser.  That
script fails on my machine, so I'm stuffed.  Anybody know a mail address
to get in touch with the bazaar team?

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

Thanks!

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Karl Fogel]

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

>There doesn't seem to be a bzr equivalent of
>http://cvs.savannah.gnu.org/viewcv;

There is; it's called loggerhead.  But it's broken on Savannah right
now.  See https://savannah.gnu.org/support/index.php?107142.

> 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.  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?  (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.)

> Even updating one's repository takes many
>minutes, something which took only a few seconds with CVS.

Yes.  But remember: https://savannah.gnu.org/support/?107077
(which is actively being worked on).

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

>At Stefan's suggestion, I tried
>
>  $ bzr diff -r tag:EMACS_23_1 lisp/progmodes/cc-*.el
>
>.  This crashes bzr.  I've just updated to the latest version of bzr
>(2.1.0), and it still crashes.  So keen are bzr's developers to get
>decent bug reports that they make you register (on "launchpad") before
>they'll deign to permit you to submit one.  They insist on you
>submitting this bug report via a script running in a web-browser.  That
>script fails on my machine, so I'm stuffed.  Anybody know a mail address
>to get in touch with the bazaar team?

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

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.

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

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

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

-Karl

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

[Andreas Schwab]

Karl Fogel <kfogel@red-bean.com> writes:

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

$ time git log --all > /dev/null
4.764user 0.218system 0m5.393selapsed 92.36%CPU

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

No.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Karl Fogel]

Andreas Schwab <schwab@linux-m68k.org> writes:
>Karl Fogel <kfogel@red-bean.com> writes:
>> That's for the entire history of the project.
>
>No.

It's not?  (Care to explain more?)

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

[Andreas Schwab]

Karl Fogel <kfogel@red-bean.com> writes:

> Andreas Schwab <schwab@linux-m68k.org> writes:
>>Karl Fogel <kfogel@red-bean.com> writes:
>>> That's for the entire history of the project.
>>
>>No.
>
> It's not?  (Care to explain more?)

$ echo $(($(git rev-list --all | wc -l) - $(git rev-list master | wc -l)))
2945

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Andreas Schwab]

Andreas Schwab <schwab@linux-m68k.org> writes:

> Karl Fogel <kfogel@red-bean.com> writes:
>
>> Andreas Schwab <schwab@linux-m68k.org> writes:
>>>Karl Fogel <kfogel@red-bean.com> writes:
>>>> That's for the entire history of the project.
>>>
>>>No.
>>
>> It's not?  (Care to explain more?)
>
> $ echo $(($(git rev-list --all | wc -l) - $(git rev-list master | wc -l)))
> 2945

Or shorter:

$ git rev-list --all ^master | wc -l
2945

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Eli Zaretskii]

> From: Karl Fogel <kfogel@red-bean.com>
> Date: Mon, 05 Apr 2010 11:32:56 -0400
> Cc: emacs-devel@gnu.org
> 
> > Even updating one's repository takes many
> >minutes, something which took only a few seconds with CVS.
> 
> Yes.  But remember: https://savannah.gnu.org/support/?107077
> (which is actively being worked on).

Thanks.  Any ETA?  It's really annoying to wait 2-3 minutes each time
I do a simple "bzr up", and similarly for "bzr ci" to the public
repository.

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

Well, yes, but the quality of the Bazaar docs leaves a lot to be
desired.  E.g., I just learned (through a question posted to the
Bazaar list) that to fully revert a tree to a certain old revision,
one needs to do a "bzr update -rNNN" rather than "bzr revert -rNNN".
There's nothing about this important fact in the Bazaar User Reference
Guide.

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

[Stefan Monnier]

>> Yes.  But remember: https://savannah.gnu.org/support/?107077
>> (which is actively being worked on).
> Thanks.  Any ETA?  It's really annoying to wait 2-3 minutes each time
> I do a simple "bzr up", and similarly for "bzr ci" to the public
> repository.

FWIW, it will be an improvement, but don't expect it to become
zippy either.

> Well, yes, but the quality of the Bazaar docs leaves a lot to be
> desired.  E.g., I just learned (through a question posted to the
> Bazaar list) that to fully revert a tree to a certain old revision,
> one needs to do a "bzr update -rNNN" rather than "bzr revert -rNNN".

Of course, this actually depends on what you define as "fully revert
a tree to a certain old revision".  If the intention is to undo the
changes since that revision, then "bzr revert -rNNN" is the right
answer, IIUC.  Whereas if you want to revert to revision NNN to
reproduce a bug there, then "bzr update -rNNN" is probably what
you want.

"bzr revert" is kind of like "cvs update -p", whereas "bzr update" is
kind of like "cvs update".


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 05 Apr 2010 15:44:50 -0400
> Cc: Karl Fogel <kfogel@red-bean.com>, emacs-devel@gnu.org
> 
> >> Yes.  But remember: https://savannah.gnu.org/support/?107077
> >> (which is actively being worked on).
> > Thanks.  Any ETA?  It's really annoying to wait 2-3 minutes each time
> > I do a simple "bzr up", and similarly for "bzr ci" to the public
> > repository.
> 
> FWIW, it will be an improvement, but don't expect it to become
> zippy either.

Slashing 2/3 of the time (according to Óscar) would make it comparable
to CVS for me, with bound branches.  And that's already a big win.

> "bzr revert" is kind of like "cvs update -p", whereas "bzr update" is
> kind of like "cvs update".

I understand this very well, once someone explained.  But the point
was that a manual which does not say that in the first place is not
really adequate.

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

[Karl Fogel]

Eli Zaretskii <eliz@gnu.org> writes:
>Thanks.  Any ETA?  It's really annoying to wait 2-3 minutes each time
>I do a simple "bzr up", and similarly for "bzr ci" to the public
>repository.

Nope, no ETA.  There appears to be only one admin at Savannah who wants
to or is able to help me work on this (Sylvain), and he's super busy.

I've posted a plan with a patch for some files on bzr.sv; Robert Collins
(bzr developer) is helping me iron out some elements of it.  Watch the
bug for more, is all I can say.

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

[Óscar Fuentes]

Karl Fogel <kfogel@red-bean.com> writes:

[snip]

>> 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.  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?  (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.)

[I'm not the OP]

Showing the log of a file or directory is much slower on bzr than on
CVS. `annotate' takes a few seconds for CVS but half a minute for bzr
with a warm cache on a 2.4 GHz Intel Q6600 CPU, which can be considered
a quite decent machine. `log file' and `annotate' are unbearably slow on
my netbook.

I extensively commented about this on the bzr ml and the response was
"making bzr faster is not one of our priorities."

>> Even updating one's repository takes many
>>minutes, something which took only a few seconds with CVS.
>
> Yes.  But remember: https://savannah.gnu.org/support/?107077
> (which is actively being worked on).

For the last months I was comparing update times, and Launchpad's smart
bzr server requires on average 30% of the time that the dumb server at
Savannah takes. This may sound impressive, but it is still way slower
than CVS. It may be unreasonable to compare CVS and bzr on this aspect,
but other well-known dVCS systems manage to be much faster than bzr
while moving around revisions.

So, I can understand Alan's frustration if he does not make use of the
dVCS features. OTOH, I'm quite happy about Emacs migration and I'm
convinced that more and more Emacs hackers will come to appreciate the
advantages of a dVCS, although bzr possibly is not the one who brings
the best experience right now.

[snip]

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

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

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

[Andreas Schwab]

Alan Mackenzie <acm@muc.de> writes:

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

$ time bzr log -n0 --show-ids lisp/progmodes/cc-engine.el > /dev/null
8.909user 0.216system 0m9.282selapsed 98.30%CPU
$ time git log -- lisp/progmodes/cc-engine.el > /dev/null
3.471user 0.086system 0m3.620selapsed 98.28%CPU
$ time bzr log -n0 --show-ids lisp/progmodes/cc-engine.el | head -1
------------------------------------------------------------
8.746user 0.181system 0m9.064selapsed 98.48%CPU
$ time git log -- lisp/progmodes/cc-engine.el | head -1
commit 988562867ec75bdbfc44d317fa2cb15fbd43dc00
0.013user 0.012system 0m0.024selapsed 103.85%CPU

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Chad Brown]

[-- Attachment #1: Type: text/plain, Size: 1570 bytes --]


On Apr 6, 2010, at 7:31 AM, Alan Mackenzie wrote:
> 
>> ?  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).

It's an acronym for `Compiled Help file (Microsoft)' -- does that tell you 
everything you need to know? :-)

It's a format used to make HTML help file bundles for MS's `help viewer'.
You almost certainly don't care.

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

I don't disagree at all, but you might find it helpful to spend an hour or so
digging through

	http://wiki.bazaar.canonical.com/BzrGlossary/

In general, the docs seem to assume that you're either already familiar with
vcs concepts and are just looking for the bzr keywords, or that you don't 
care at all and are just looking for the right set of magic words to say to 
avoid angering the wizards.  I suspect that the aim to cater to as many 
different `methodologies' (what we've been calling workflows on this list) 
has encouraged a doc style that's so detail-agnostic that it's hard to ever 
find useful content.

I hope that helps,
*Chad

[-- Attachment #2: Type: text/html, Size: 2445 bytes --]

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

[Juri Linkov]

>>> ?  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).
>
> It's an acronym for `Compiled Help file (Microsoft)' -- does that tell you
> everything you need to know? :-)

Why the official GNU dVCS provides its documentation in the Microsoft format,
and not in the GNU documentation format Texinfo?

-- 
Juri Linkov
http://www.jurta.org/emacs/

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

[Eli Zaretskii]

> 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

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

[Stephen J. Turnbull]

Alan Mackenzie writes:

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

As Eli points out, you need to learn (at least a little bit) how to
"think Bazaar".  In CVS getting logs for a single file is faster than
for the whole project because you only get the logs you want, from one
,v file.  In Bazaar, getting logs for a single file is more costly
than getting them for the whole project because you have to get all
the logs, then filter out the uninteresting ones.

This is because you do not commit changes to a file in Bazaar (or any
of the other dVCSes); you commit all the changes to the tree.  There's
only one log for all the history of the branch.

Also, "bzr log -n0" is *much* slower than "bzr log" because the former
needs[1] to compute the whole history DAG to decide where to put each
commit before displaying them, while the latter just chases the
principal parent chain, and can start displaying log entries
immediately.

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

Currently, yes.  The developers are aware that the docs have some
problems, and some progress is being made.

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

Sure.  The direct benefit is that you can work on a branch with little
effort, temporarily isolating the changes you're working on from
interference with others' work.  You can choose when to pull upstream
changes into your branch, and which changes to accept.  In CVS (or SVN
up to 1.4 or so), pulling multiple times will usually result in
annoying, unnecessary merge conflicts.  You can also choose to pull
from multiple upstreams (which all must be branches off the same
mainstream, of course), and integrate those changes.  It is this last
integrative function that is most characteristic of dVCS (SVN still
can't do this very well, and not at all across separately administered
mirrors).

The indirect benefit is a substantial savings in time and frustration
for developers who enjoy the direct benefits, and that means more
rapid delivery of new code to all users, including you.

 > My question wasn't rhetorical.  ;-)  I'd like having local history if I
 > could access it in less than historical time,

That way of stating it is quite rhetorical, though.


Footnotes: 
[1]  "Needs" in the current implementation.  It's possible to improve
this, and some work is being done at the moment.

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

[Eli Zaretskii]

> Date: Mon, 5 Apr 2010 14:56:37 +0000
> From: Alan Mackenzie <acm@muc.de>
> 
> 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.  There doesn't seem to be a bzr equivalent of
> http://cvs.savannah.gnu.org/viewcv; bzr log is so slow (40 seconds) as
> to be only somewhat useful.

Try "bzr log --line -l100" instead (replace 100 with a larger number
if you want to look farther back).  This takes about 3 seconds on my
box with a cold cache, 1 sec with a warm cache.

> Even updating one's repository takes many minutes, something which
> took only a few seconds with CVS.

Which reminds me: any chance to get bzr+ssh "smart server" any time in
this millenium?

> At Stefan's suggestion, I tried
> 
>   $ bzr diff -r tag:EMACS_23_1 lisp/progmodes/cc-*.el
> 
> .  This crashes bzr.

It throws a fatal error because it does not find some revision it
thought it should:

  bzr: ERROR: bzrlib.errors.NoSuchRevision: CHKInventoryRepository('file:///D:/gnu/bzr/emacs/.bzr/repository/') has no revision ('cyd@stupidchicken.com-20090730011415-1ur84cd4r2dats1v',)

"bzr revision-info cyd@stupidchicken.com-20090730011415-1ur84cd4r2dats1v" 
indeed does not find such a revision neither on the trunk nor on the
emacs-23 branch.  What is that revision, and why did it disappear?
Does it mean our repository is corrupted?

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

  mailto:bazaar@lists.canonical.com

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

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> "bzr revision-info cyd@stupidchicken.com-20090730011415-1ur84cd4r2dats1v" 
> indeed does not find such a revision neither on the trunk nor on the
> emacs-23 branch.  What is that revision, and why did it disappear?

It only exists on the EMACS_32_1_RC branch.

> Does it mean our repository is corrupted?

There is no way to clone a bzr repository as a whole.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Alan Mackenzie <acm@muc.de>,  emacs-devel@gnu.org
> Date: Mon, 05 Apr 2010 17:43:29 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > "bzr revision-info cyd@stupidchicken.com-20090730011415-1ur84cd4r2dats1v" 
> > indeed does not find such a revision neither on the trunk nor on the
> > emacs-23 branch.  What is that revision, and why did it disappear?
> 
> It only exists on the EMACS_32_1_RC branch.

Right, I thought it was EMACS_23_1_BASE.  Those names _are_ confusing.

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

[Stefan Monnier]

>> "bzr revision-info cyd@stupidchicken.com-20090730011415-1ur84cd4r2dats1v"
>> indeed does not find such a revision neither on the trunk nor on the
>> emacs-23 branch.  What is that revision, and why did it disappear?
> It only exists on the EMACS_32_1_RC branch.

I guess we should turn those important tags into branches to make it
easier to refer to them.

>> Does it mean our repository is corrupted?
> There is no way to clone a bzr repository as a whole.

We may want to post a bug report about it to Bzr anyway: I think Bzr
should either be able to (tell you to) fetch the necessary revisions, or
should try and prevent the situation from occurring (either by
automatically including the revisions referred from tags or by only
allowing tags that refer to revisions included in the branch).


        Stefan

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

[Richard Stallman]

    There is no way to clone a bzr repository as a whole.

Is that a flaw in bzr?

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

[Stephen J. Turnbull]

Richard Stallman writes:
 >     There is no way to clone a bzr repository as a whole.
 > 
 > Is that a flaw in bzr?

Yes; people often want to clone all of the branches of a project.  The
Bazaar developers agree that it's a flay, and they're working on it
(probably at low priority, I haven't seen any discussion of it on the
list in the last couple of months, but it has definitely been
discussed in the last 3 or 4 months).

I believe there is a command (perhaps in a plug-in) to list all of the
branches in a shared repository, so it is probably straightforward to
script this feature.

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

[Chad Brown]

While I'm no real fan of bazaar, wait until we want to merge the gtk-tabs branch, or the bidi branch, or the lexbind branch, or (even better) more than one of those into the mainline, and I think you'll see a a big difference versus cvs.

The fact remains that the current gnu bazaar setup is so bad that many emacs developers are intentionally choosing to use mirrors that they know to be out of date just to avoid it.  

*Chad

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

[Stefan Monnier]

> While I'm no real fan of bazaar, wait until we want to merge the
> gtk-tabs branch, or the bidi branch, or the lexbind branch, or (even
> better) more than one of those into the mainline, and I think you'll
> see a a big difference versus cvs.

No, *he* (like most people) won't.  And it's not going to be
significantly easier than when we did it in the (near) past, because we
already used to do it in a DVCS (namely Arch) thanks to Miles's mirror.

But yes, for the person handling the merge (and even more so for the
person who maintains the branch until it gets merged), it helps a lot.


        Stefan

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

[chad]

[-- Attachment #1: Type: text/plain, Size: 1622 bytes --]

On Mon, Apr 5, 2010 at 12:56 PM, Stefan Monnier <monnier@iro.umontreal.ca>wrote:

> > While I'm no real fan of bazaar, wait until we want to merge the
> > gtk-tabs branch, or the bidi branch, or the lexbind branch, or (even
> > better) more than one of those into the mainline, and I think you'll
> > see a a big difference versus cvs.
>
> No, *he* (like most people) won't.  And it's not going to be
> significantly easier than when we did it in the (near) past, because we
> already used to do it in a DVCS (namely Arch) thanks to Miles's mirror.
>
> But yes, for the person handling the merge (and even more so for the
> person who maintains the branch until it gets merged), it helps a lot.


I take your point, but my thought (perhaps not well-enough explained) was
that he (and we) would feel the benefits of it even if it was only
vicariously avoiding pain.

Let me put this another way:  If multi-tty was any indication, the sorts of
efforts represented by bidi, gtk-tabs, concurrent, and guile would be
suppressed/discouraged/obscured by a non-distributed system like cvs
compared to the ``here's my live repo'' state we have now, and we have been
very conservative in our adoption of dvcs system benefits (as evidenced by
the periodic ``why are we still doing this crud if we're using a dvcs?''
threads).

In the meantime, I'm now using bzr, because of emacs -- which I believe was
the (regardless of technical merit) reason that we adopted the system.
 Probably at least several others here are as well, so there's hope for it
to improve, as long as the growing pains aren't too onerous.

Thanks for your time.

[-- Attachment #2: Type: text/html, Size: 2071 bytes --]

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

[Stephen J. Turnbull]

chad writes:

 > In the meantime, I'm now using bzr, because of emacs....  Probably
 > at least several others here are as well, so there's hope for it to
 > improve, as long as the growing pains aren't too onerous.

As somebody who has been following the Bazaar list for years, and the
main protagonists on the GNU Arch list before that, all I can say is
"good luck".

The Bazaar focus remains what it has always been: supporting as many
features and workflows as possible.  For example, substantial effort
(ironically enough) is going into making Bazaar a good front-end for
git repositories, and another main thrust is the GUI "Bazaar
Explorer".  Another developer is busy working on a speed optimization
of "bzr log" that "only" expands the size of repos by a factor of 10
(in the prototype, of course it will get better, but clearly he is not
aiming at reducing the size of repos).  As (IIRC) Óscar reported, the
Bazaar developers think Bazaar 2.x is fast enough, and most users who
post do seem to agree (in fact, recently I've seen complaints only
from bzr@savannah users, ie, Emacs and GRUB -- most users don't use
Savannah or Launchpad, of course, they use either local repositories
or the smart server.)

I suggest that you should make your own luck.  Bazaar's development
process is relatively open, perhaps better than Emacs's --
specifically, I mean that they have a formal mentoring process for new
developers (grep for "patch pilot" in the Bazaar list archives).
Nobody would object to patches that speed up bzr.

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

[Chong Yidong]

Alan Mackenzie <acm@muc.de> writes:

>   $ bzr diff -r tag:EMACS_23_1 lisp/progmodes/cc-*.el
>
> .  This crashes bzr.

If you're working off the emacs-23 branch, try

  bzr diff -r tag:EMACS_23_1_BASE lisp/progmodes/cc-*.el

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

[Richard Stallman]

      They insist on you
    submitting this bug report via a script running in a web-browser.

I am concerned about this.  Could you show me the script?
What is its license?

I will send you the email address of the maintainer
and forward him your message.

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

[Alan Mackenzie]

Hi, Richard,

On Tue, Apr 06, 2010 at 06:43:00AM -0400, Richard Stallman wrote:
>       They insist on you
>     submitting this bug report via a script running in a web-browser.

> I am concerned about this.  Could you show me the script?
> What is its license?

When bzr detects a bug, it prompts you to report it via 
<https://bugs.launchpad.net/bzr/+filebug>.  After logging in, and so
forth, you get a page with this:

<html>
<head>
  <title>OpenID transaction in progress</title>
</head>
<body onload="document.forms[0].submit();">
  <form accept-charset="UTF-8" action="https://login.launchpad.net/+openid"
  enctype="application/x-www-form-urlencoded" method="post"><input
  name="openid.return_to" type="hidden"
  value="https://launchpad.net/+openid-callback?starting_url=https%3A%2F%2Fbugs.launchpad.net%2Fbzr%2F%2Bfilebug&amp;janrain_nonce=2010-04-06T12%3A51%3A50Z1G8Xn1"/>
  <input name="openid.realm" type="hidden" value="https://launchpad.net/"/>
  <input name="openid.ns" type="hidden"
  value="http://specs.openid.net/auth/2.0" /><input name="openid.sreg.optional"
  type="hidden" value="email,fullname" /><input name="openid.claimed_id"
  type="hidden" value="http://specs.openid.net/auth/2.0/identifier_select"/>
  <input name="openid.ns.sreg" type="hidden"
  value="http://openid.net/extensions/sreg/1.1" /><input
  name="openid.assoc_handle" type="hidden"
  value="{HMAC-SHA1}{4ba9fc17}{Xb8Z2g==}" /><input name="openid.mode"
  type="hidden" value="checkid_setup" /><input name="openid.identity"
  type="hidden" value="http://specs.openid.net/auth/2.0/identifier_select"/>
  <input type="submit" value="Continue" /></form>
<script> var elements =
  document.forms[0].elements; for (var i = 0; i < elements.length; i++) {
  elements[i].style.display = "none"; }
</script>
</body>
</html>

Sadly, this doesn't work in my browser.  Who knows what its license is?
Probably nobody has ever considered it.

> I will send you the email address of the maintainer
> and forward him your message.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Martin Pool]

On Tue, 06 Apr 2010 13:25:27 +0000, Alan Mackenzie wrote:

> When bzr detects a bug, it prompts you to report it via
> <https://bugs.launchpad.net/bzr/+filebug>.  After logging in, and so
> forth, you get a page with this:
> 
> <html>
> <head>
>   <title>OpenID transaction in progress</title>
> </head>
> ...
> 
> Sadly, this doesn't work in my browser.  Who knows what its license is?
> Probably nobody has ever considered it.

Since the code is part of Launchpad, I think the licence is GNU AGPLv3.  
Though really this particular page is barely code at all, just a bunch of 
per-user variables.

This is part of the implementation of the OpenID authentication 
protocol.  If it doesn't work in your browser that's a bug, and if you 
tell me about your setup (off list if you prefer) I will pass it on.

-- 
Martin 

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

[Jason Rumney]

Alan Mackenzie <acm@muc.de> writes:

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

Indeed. The designers of the system seem to assume everyone in the world
can get multiple Mb/s connections to the project servers.

[#########\          ]   2153KB     4KB/s | Fetching revisions:Inserting stream

I find bzr quite unusable here.

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

[Alan Mackenzie]

Hi, Jason,

On Tue, Apr 06, 2010 at 10:35:57PM +0800, Jason Rumney wrote:
> Alan Mackenzie <acm@muc.de> writes:

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

> Indeed. The designers of the system seem to assume everyone in the world
> can get multiple Mb/s connections to the project servers.

> [#########\          ]   2153KB     4KB/s | Fetching revisions:Inserting stream

> I find bzr quite unusable here.

By the way, do you understand that message?  What is the "stream", and
into what is it being "inserted"?

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Stephen J. Turnbull]

Alan Mackenzie writes:

 > > [#########\          ]   2153KB     4KB/s | Fetching revisions:Inserting stream

 > By the way, do you understand that message?  What is the "stream", and
 > into what is it being "inserted"?

It's internal gobbledygook.  Almost nobody understands those messages,
but they do give you some hint about what's happening that you can
correlate with past invocations of bzr up (which is more than one can
say about the progress bar, which appears at "halfway", and stays
there until done).

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

[Óscar Fuentes]

Alan Mackenzie <acm@muc.de> writes:

[snip]

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

Using Distributed Version Control Sytems (dVCSs) supports the goals of
the Free Software movement.

Free Software grants the user the right to access the source code so he
can study it. Just as producing well written source reinforces this
right, giving easy access to the VC history does likewise. Easy access
here means local access, so the user can perform whatever operation he
pleases without the constraints of a remote server.

Free Software grants the user the right to modify the source
code. Distributed VCs makes this much easier, as it is trivial to create
your personal fork (branch) and integrate changes from upstream. Compare
this with maintaining sets of patches.

Free Software means granting the user the right to re-distribute his
modified software. With a dVCS, publishing your personal branch is
almost as easy as putting a tarball for download, but with the added
advantage for your users of having an easy method for knowing exactly
how your modified source differs from the master project, and providing
the capability of easily picking specific changes and integrating them
on other forks or on the original project, which includes allowing your
users the capability of basing their changes on top of yours (i.e. by
forking your source code).

Thus dVCSs are excellent tools for administering your local changes and
sharing them with the community. This is a strong encouragement for
people who is considering start hacking on some piece of software.

Implicit conveniences:

If the master project vanishes, you can resurrect it in no-time without
missing a bit of development history.

If you wish to collaborate with others developing a fork (branch) of the
original project, dVCSs makes this trivial.

If you wish to contribute your changes to the original project, dVCSs
makes this substantially easier than previous tools.

IMO GNU should recommend using Distributed Version Control Systems to
all developers working on Free Software.