Usage discussion from the GNU Emacs project.

[Stephen J. Turnbull]

Jason Earl writes:

 > In other words, since this is something that is only going to happen
 > infrequently (once per machine you hack on) you just spent more time
 > writing this email than you would have saved assuming Emacs were to
 > switch to git :).

You are entirely missing the point.  For reasons I won't go into I am
*highly* unlikely to contribute code to Emacs for a while.  I am doing
thisfor a completely different reason: I do user support, and I expect
to hear complaints about this *very* frequently during the transition.
And if the *first* experience is "don't even think about using bzr to
bootstrap your repository, use wget", or "3.5 times as slow as the git
repo advertised right next to it", I expect that every difference to
the detriment of bzr is going to cause the "bzr is just slow" meme to
proliferate.

And people are recommending bound operation on the emacs-devel list!
How s-l-o-w can you go?

If Bazaar doesn't care, I don't care.  But bzr is going to get a bad
rep in a high profile, vocal community if something isn't done about
the way things are going.  One can only push back against RMS so far;
I've gone as far as I dare, and I suspect that (as usual) he's already
stopped reading my posts to emacs-devel.

 > And, as you pointed out, you can go to lunch while doing your first bzr
 > branch (or read your email, or play nethack, etc.).

It is *not about me*, and it's *not about Óscar*, either.  We
understand the tradeoffs.  So does Stefan Monnier for that matter, but
he seems to be occupied with other tasks.  RMS, on the other hand, is
pushing hard to set up some of the worst possible workflows as
"recommended" in exchange for being able to keep the familiar and some
simplicity in the initial "checkout" (or no-quotes checkout, since
lightweight checkouts have caught his fancy!)

 > This isn't really about git vs. bzr, its about savannah with git and
 > launchpad.

No, it is not.  Launchpad is not an option for Emacs, and it isn't
very much an option for most GNU projects.  Remember, Emacs is using
Bazaar over git, at great cost to the developers (git could have been
up and running at least a year ago) *purely because Bazaar is branded
"GNU" and git is not*.

And it's going to look really good for Bazaar if the Emacs people are
all hosting their sandboxes on Launchpad and github(!).

 > Although I will say that branching from a smart server does take quite a
 > bit of server resources.

 > It is ironic that savannah has better git support than bzr support.

Get used to it.  This is the way the world works.  There is a reason
why git and hg are justly popular in the open source development
community.  They work with the world as it is, they are easy to set up
both as CGI one-offs on a personal website and scaling to
installations as large as SourceForge and Savannah.  People (here I
mean OSS developers) are used to scripting around half-baked UIs, but
there is no way to script around network delays and the like.

 > The git fans are going to complain.  That is essentially inevitable.
 > You are being a good sport about the switch (including writing
 > documentation) but *you* are going to complain.

No, I'm not going to complain; I'm going to use git where appropriate
(if I have a complex, not even approximately linear DAG), and other
tools where appropriate.

What I'm complaining about here is bzr fans complaining about the "bzr
is slow" meme.  Something needs to be done about that.  There's
clearly a "bzr doesn't need to be effectively set up because users
don't care very much" meme incubating at Savannah.  That's really not
good.

 > Yes, as I said better hardware does seem to extend git's lead (assuming
 > you have access to a smart git server).

I don't know anywhere except my personal host that doesn't provide a
git server.  Access to git smart server is easy to get.  Why access to
bzr smart server is less so, maybe it's just Savannah?  Please tell me
it's just Savannah and I'll feel a lot better.

 > > Again, the git fans on emacs-devel are *not* going to compare to CVS.
 > > Telling them to do so is just going to convince them that Bazaar
 > > doesn't want to respond to performance issues.
 > 
 > Yes, and RMS is only slightly more likely to change his mind on this
 > particular issue than he is on his choice of text editors.

It doesn't matter to Emacs if he sticks with Bazaar; Bazaar is a good
system that is only going to get better.  It's the bad PR for Bazaar
that I care about, and the bad CVS-like workflows that are being
recommended (at least, RMS is thinking that way) as the way to get
started with Bazaar.

I suppose a lot of why I'm presenting this way is my frustration with
trying to get a good plan for the transition set up over at
emacs-devel.  Maybe RMS is unusual, but then *exactly* the same
conversations were had at Python.  "What do you mean I have to set up
a local repository?  That's complex!  The centralized workflow using
'checkout --lightweight' looks like the way to go to me.  Boy is bzr
slow.  Good lord, Debian stable is on bzr 0.99.[1]"  Ad nauseum.

Why does history have to repeat itself?  Why do I keep banging my head
against this brick wall?  "Doctor-to-Steve: if it hurts whan you bang
your head against a brick wall, don't do that!"

Footnotes: 
[1]  I forget what it was, but lenny was in testing when Python's PEP
374 was being written; the Python sysadmins were a little grudging
about allowing the bzr that would be in lenny as the "must-support"
minimum, they wanted current Debian stable -- maybe bzr wasn't even in
stable at the time.