Feedback from evaluation in a corporate environment

[Stephen J. Turnbull]

Martin Pool writes:
 > 2010/1/8 Stephen J. Turnbull <stephen at xemacs.org>:
 > >  > which as I understand is comparable in performance to Mercurial and
 > >  > GIT now.
 > >
 > > Don't believe all the marketing fluff you read.  Bazaar is comparable
 > > in performance to Mercurial or git *only* if you adapt your workflow
 > > to use optimized Bazaar facilities, including smart servers, shared
 > > repos, and lightweight checkouts.
 > 
 > Smart servers are a kind of funny example to pick, because the option
 > to do without one and push branches over webdav, sftp or ftp is, I
 > believe, unique to bzr.

Sure.  Nevertheless, the mere availability of HTTP and sftp has caused
me and Karl an IMMENSE amount of aggravation over on emacs-devel
because the Savannah admins chose to implement HTTP and sftp only --
that was the easy thing to do because they understood the security
implications.  Results: The phrase "bzr is unusable" has been posted
*twice* in the last twenty-four hours (by different developers).

 > For read access, measurements posted to this list last year had bzr
 > performing substantially better than git over dumb http.

Sure, but that is not the comparison the Emacs users are seeing in
their own workspaces.  They're seeing git server and cvs server
vs. bzr http and sftp, and they are not pleased.  It has been
explained several times that this is not a bzr problem, it's an admin
cockup, but ... nobody seems to be reading those threads until they
run into a 90-minute initial branch from Savannah, or a 40-minute
local branch because they were sloppy about following directions.

Then they find out that this has come up before, and although some
will ask why the Savannah admins don't address it, others have more
sympathy for the overworked GNU staff than they do for the Bazaar
developers.  And *they* ask why doesn't bzr use the HTTP range header
or some such.  Just plausible enough to make bzr look bad to anybody
with less knowledge than I have.  You see?  The cup is half-*empty*!

 > More generally, yes, it's possible to use most tools in a way that
 > makes them slow, and we have more to do to make the obvious way always
 > the best way.  Read the manual, or ask, or just try it.  It's not hard
 > to use bzr in a way that makes it fast and easy.

Yeah, I said that too.  But what you perhaps don't know is that
Richard Stallman finds that unacceptable -- he insists that the Emacs
maintainers find a way to make *existing Emacs workflows*, or
something very close to them, fast and easy.

Messrs. Budden and Moszkowicz are somewhat more accomodating, but they
clearly are not interested in asking their users to read manuals, ask,
or just try it.  In Uri's case, he *did* try it, and while he was
polite enough not to dismiss bzr out of hand, he did say that the
performance he experienced won't cut it.  IMO, *that performance needs
to be explained* in terms that allow him to be confident that he can
consistently get the performance he needs as the workflows evolve, not
just explained away for each example as it comes up.

Now, I wouldn't worry too much about the Emacs developers -- they're a
cranky bunch, but RMS is adamant that bzr is the right VCS for Emacs,
so they'll get used to it, and probably most wiill learn to like it.
Messrs. Budden and Moszkowicz (especially the latter, I suspect)
represent an important set of markets for you, though.  Making it easy
for them to implement their workflows, without falling into any
performance traps, would be a big plus for Bazaar marketing IMHO.