BDFL decision of Python's DVCS

[Stephen J. Turnbull]

Russel Winder writes:

 > So how does Mercurial evolve -- or did they get the right format
 > first time and will never have to change it?

"Right"?  No; there are things like 100% correct rename handling that
would require a new repo format, and upgrade of existing repos to take
advantage of it.  But good enough[tm], and very high performance for
basic operations (specifically, reading the DAG and commit metadata
into memory, and checkout of arbitrary revisions) so that any
awkwardness in less important operations can be hidden from the user
almost completely without frobbing the repo format, at least not in a
visible way.

 > Another implication here is that Mercurial has better managed its
 > relationship with all the distro packaging people -- including I
 > assume Windows?

I don't know if it's a question of managing the relationship, but
here's what Mercurial has to offer along those lines:

http://www.selenic.com/mercurial/wiki/index.cgi/BinaryPackages

Pretty impressive.  Note that a lot of those URLs point to
"mercurial.berkwood.com", so I would guess that somebody besides
Selenic is making gelt from Mercurial consulting, and this is their
return to the community.

I don't know what it would take to get Bazaar into that kind of
milieu.  There's a lot of money chasing kernel development, so I would
guess that some slops over into the VCSes that are most popular among
kernel developers.  At current pace, maybe by June kernel scale will
be in reach for Bazaar too?

 > > I don't agree that, as presented in the PEP, the hg-based workflow
 > > mapped better to SVN than does bzr, but some people apparently thought
 > > so.  I suspect *latent* complexity has something to do with that.
 > 
 > This is an interesting point.  I suspect that social rather than
 > technical factors are at work.

Yes and no.  Yes, Guido explicitly admits that social factors have a
lot to do with his decision.  However, he consulted closely with Brett
Cannon (the PEP proponent) who by now is fairly well-versed in all
three candidate VCSes.  And no, this

 > I hypothesize that someone well versed in Mercurial found a nice
 > way of working for themselves and announced it.

is false.  Brett decided to Do Something about modernizing Python's
infrastructure, and thus PEP 374 (http://python.org/peps/pep374/) was
born.  Originally it was supposed to be a bake-off between Mercurial
and Bazaar, but by popular demand git got shoehorned in too.  The
rules of the contest were that Brett posted a set of common Python
workflow tasks in Subversion, and the proponents were to explain how
to do the same thing in their assigned VCS.  Then finally Brett did
some benchmarking of important tasks.

All of the VCSes were able to reproduce the svn workflow excellently,
often with substantial technical improvements over svn, except that
emulating "svnmerge.py block" is quite kludgy in all of them.  None
really demonstrated a technical advantage over the others for Python's
workflow.  In particular, Bazaar advocates mentioned correct rename
handling several times, and the response was a deafening lack of
enthusiasm.

 > This got picked up and became a "fact" rather than just one
 > person's impression.

The only "facts" to come out from the PEP are that all three are good
enough, all three are definitely superior to Subversion, Bazaar
performs distinctly more poorly than the other two, and Bazaar is less
mature than the other two.  These *are* *facts* at the present time.
The last two may be expected to change dramatically in the next couple
of months, but that's too late; the decision wanted to be made at
PyCon, and it was.  Bird in the hand and all that.

Anybody who wants to extract some factoids from the PEP can do so, I'm
sure.  But the response on Python-Dev so far has been "if it was that
close, I'm glad you made the call.  Now, let's go!"  Nobody is cutting
on the losers.

 > I find this conservatism and indeed almost Ludditism very interesting.
 > A priori I would have thought that Python developers were cutting edge
 > people, wanting to do the best thing.  Instead I get the impression of
 > people who don't want to change, are having change forced on them, and
 > so are rebellious.

You're missing the point.  Python has in the last couple of years made
several major changes to their workflow, and one major non-change.
The most important changes are (a) the doubling of simultaneous active
branches from trunk and stable to {trunk,stable} X {2.x,3.x}, and (b)
the adoption of timed release planning.  These changes are seriously
stressing the developers.  The most important non-change was the move
from SourceForge tracker to Roundup.  This has been successful because
the workflow has not been required to change by this move, and even
bug numbers have been moved.

The #1 priority of PEP 374 is to replicate that success.  #2 is to
improve over Subversion (which all clearly do).  #3 is optimize the
benefits, and frankly, for the Python workflow, I don't see any
features in any of the candidate VCSes that makes it worth a 1 in 1
million chance of screwing the pooch on #1.  "Premature optimization
is the root of all error" -- which may very well be the unwritten 20th
tenet of Python Zen.

 > Git somehow managed to get the zeitgeist leading people to choose
 > it because they felt they should, rather than checking that the
 > tool fitted their favoured workflow.

After working on PEP 374, I just don't see that as a problem.  All the
candidate dVCSes will work with all the workflows I've heard of,
although they all require substantial adaptation for, say, your bzr-
over-svn use case, and each of them has advantages and disavantages
for such use cases.  Within that general competence, though, there are
personal preferences about tool style, and there the differences
between git and hg/bzr are dramatic.  I'm not really sure what the
difference is between hg and bzr in that respect.  (I really like
multi-branch repos, and I really like operating on the DAG the way I
operate on lists in LISP, so I'm not the one to ask.)

git is very scriptable, and deliberately exposes the DAG to the world,
but does so safely.  This led to (1) the gitk tool, which basically
kicks the legs out from under bzr log (bzr log format is wonderful as
ASCII art, but who cares when gitk gives it to you in living
Technicolor?), and (2) rebase and filter-branch, which Bazaar and
Mercurial had to be dragged kicking and screaming into supporting (and
which required hacking into the Python internals to support).  I
think both of those are places where more effort/acquiescence to
popular demand would pay big dividends to Bazaar.

Specifically, these are really big advantages if you do things like
converting old CVS repos and so on, where you *know* the automated
tool will get the branching wrong.  It's also a marketing plus,
knowing that you can probably efficiently script yourself back out of
any trouble you get yourself in.

 > The Big Win for Bazaar for me is still the interworking with Subversion
 > -- the fact that I can have a Bazaar branch stored in a Subversion
 > repository.

Yup.  That's a real technical advantage that (unfortunately for this
sweepstakes) Python really doesn't care about.

 > FInally (!):  there is another issue here that again is one of social
 > psychology and perception, not of fact:  people perceive Git and
 > Mercurial to be FOSS projects, whilst Bazaar is a Canonical product.

That's true, there is that perception, and I guess it matters to many
people.

 > The question is how to tap into whatever allowed Eclipse, the well known
 > IBM product to gain majority market share, and for NetBeans, the well
 > known Sun product (well they bought the company), to become the young
 > pretender.  It's all a marketing problem.

Well, no.  In the market for developer mindshare, you need a
competitive product, smoke and mirrors is not enough.  Bazaar's
technical advantages are minute (very few projects rename files at
rates of more than a tiny handful per year), its disadvantages have
been large (5:1 "$VCS clone" ratio, 10:1 or worse "$VCS log"), and
some claims (superior log output and merging and better UI) are
subjective at best and many consider them overblown.  It's only as you
get into Bzr's 1.teens that you have something that's starting to look
competitive overall.

But as I say, bzr needed to be where it is now 3 months ago.  Then it
would have been a horserace.