Usage discussion from the GNU Emacs project.

[Jason Earl]

"Stephen J. Turnbull" <stephen at xemacs.org> writes:

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

Unfortunately, I suppose at this point I think that this is inevitable.
Bzr simply is not as fast as git, even if the Savannah admins wanted to
play ball.  Which they don't.

I still don't think that the missing smart server is a deal breaker.
Yes it means that the first pull into your repository is slower than it
need be, but subsequent pulls aren't bad.

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

I think that *I* am one of the people recommending a bound branch.  This
might be a case where I am simply unaware of bzr's shortcoming.  I was
under the impression that bound branches worked fairly well.  If you are
only going to have a single checkout and you want to use bzr like cvs
aren't bound branches an acceptable solution?  You shouldn't even need a
repository.

Perhaps I am confused.  I will have to run some tests and see what I
come up with.

Either way, I have to admit that I have learned more about bzr (and git
for that matter) responding to your emails than any other method I had
previously considered.  Thank you for that, truly and sincerely.

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

Ah, I misunderstood.

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

I A single light weight checkout would be disastrous.

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

I didn't find setting up a bzr smart server to be difficult.  In fact, a
read-only bzr server is available by default.  Just add a line to
inetd.conf.

If you just need a one off bzr server it has the advantage over hg and
git that all you need is ftp to be able to push.

The problem isn't that bzr is especially difficult to install, the
problem is that the Savannah admins apparently don't want to install
from source.  I imagine that if Emacs were switching to hg (for example)
the folks doing the Mercurial change wouldn't want to be stuck with what
is in Debian stable.  The fact that bzr has made a lot of progress
actually seems to be working against it here.

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

I agree.

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

It is just Savannah.  The requirements for a bzr server and a writeable
git server are actually very similar.  Basically identical.

>  > > 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!"

There was clearly some history that I was unaware of.

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

Once again, thanks for the conversation.  I will admit that this whole
process has me somewhat discouraged as well.  I did the initial
conversion of the Emacs repository because I thought it would be an easy
way to get more involved with the Emacs community.  Now, coming up on a
year later, I am worried about whether I have been helpful or not.

On the bright side, I have really learned to appreciate bzr.

Jason