Usage discussion from the GNU Emacs project.

[Ian Clatworthy]

Stephen J. Turnbull wrote:

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

Yes, we fall into the trap of flexibility causing confusion. We ought to
be far more rigorous about saying "this is how you work with Bazaar" and
only offering the flexibility as a "now you know the basics, you might
like working this way instead". I've put together a tutorial overnight
that takes this approach, using Emacs as the example project. I'd like
to see http://www.emacswiki.org/emacs-en/BzrForEmacsDevs adopt that
approach too.

Looking back at the Python evaluation, the other trap we need to avoid
is ensuring the initial migration being tested is as compact as
possible. It's super convenient to convert repositories using bzr-svn
but those repositories can be much larger than those generated by
fast-import (as the former uses custom internal ids while the latter
uses vanilla bzr ids). If the repo size is 30% bigger than it needs to
be, then our transfer times look much worse than the actually are.

Ian C.