Usage discussion from the GNU Emacs project.

[Stephen J. Turnbull]

Jason Earl writes:

 > Unfortunately, I suppose at this point I think that [an invidious
 > comparison with git's performance] is inevitable.

Could be.  But good PR can help.

 > Bzr simply is not as fast as git, even if the Savannah admins wanted to
 > play ball.  Which they don't.

True on both counts, but I think bzr is plenty fast to keep people
happy, *if* we can get Savannah to play ball.

Where I feel slowness in bzr is in startup.  On Mac OS X, "git log
--limit 150" takes much less time than "bzr --version", or "hg
version".  I think it's just the Python interpreter plus imports of a
lot of modules; not something that can be "fixed" in software without
a radical (and undesirable) redesign.

An interesting concept there might be a "bzr server" for *local*
operation.  Ie, you "bzr log" on your favorite project.  bzr looks,
finds no server, forks one off.  After that, bzr commands will be
blindingly fast because there's almost no startup overhead.  But this
would be expensive.  On the other hand, it's very similar to
multibuffer/emacsclient operation in Emacs, maybe there's some synergy
here if Emacs people want to help develop such a feature.

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

Maybe it's not as slow as I think it would be.  I've only used them a
little bit.

 > I think that *I* am one of the people recommending a bound branch.

Hey, everybody recommends bound branches!  Karl did, too, specifically for
the "trunk" mirror (in BzrForEmacsDevs), and I'm not even going to
mention changing that (oops, but you know what I mean).

What I meant here was a *standalone* 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?

Using bzr like CVS is not acceptable as *recommended* practice for
Emacs.  The immediate problem is that unless people commit coherent
changesets, it's antisocial.  It horks the logs, because your local
stream of changes becomes the mainline.  We really want people merging
collections of related changes as *one* merge commit on the mainline,
not as a series of direct commits (perhaps interleaved with others'
commits).  There's also the aggravated race condition that develops if
a lot of people use bound branches as their *primary* workspaces.

Not to mention that it's not going to help the developers grow.  We
really want people to get the full benefit of bzr, and using it like
CVS just doesn't cut it there.  We want people to get used to making
feature branches without even thinking about it.  We want them to get
used to committing stuff they don't fully understand, then commit
tweaks, and finally merge the whole branch.  We want them to get used
to using merge to update their longer-running local workspaces.  (Yes,
I know about "bzr merge --force", but that's not really for newbie bzr
users.)

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

Good deal!  You're very welcome.

 > A single light weight checkout would be disastrous.

But a single bound branch wouldn't be much better, for the reasons
enumerated above.  It would be better for the individual, yes, but the
effects on the project workflow would be detrimental.  Or, more
precisely, it would impose continuation of the CVS workflow on all the
developers, including those who want to develop a nice workflow.

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

"I feel a lot better."  Yay!

 > Now, coming up on a year later, I am worried about whether I have
 > been helpful or not.

Of course you've been helpful.  Without your repos, nobody would have
had any experience with an Emacs-sized repo until few weeks ago.  And
the complaints of the Emacs users at that time were certainly a factor
in a *long* series of performance improvements.

It also had a lot of impact on the Python decision, in the sense that
experience with your repos (unfortunately) confirmed the measurements
that they were making on early conversions of their Subversion repo.

Granted, I think the timing was serendipitous; bzr had just matured to
the point where serious tuning was number one priority around the time
that Emacs decided on bzr.  IIRC the "improve performance" drive was
already underway at that point, but hadn't produced a lot of visible
results yet.