Barry Warsaw writes:
think this is a good time to ask whether we should move from
Subversion to Bazaar <http://www.bazaar-vcs.org> for our source code
revision control system.
I would rank Bazaar(-ng == bzr) third behind git and Mercurial. I like git because it tastes like Mom's home cooking. Er, I mean, the git model has a strong flavor of Lisp, although "cons", "car", "cdr", and "get" are about the only operations fully implemented yet. This has long been the way I think about vcses, despite long flirtations with GNU Arch and Darcs. While Linus is not primarily interested in vcses, the fact that he chose to implement his personal vcs as a dialect of the oldest (and still going strong) computer language is indicative of future possibilities. If there's going to be another quantum leap in vcses in the next few years, my bet is that the prototype will be a child of git.
Mercurial is second because it is likely to be the choice of my main project, XEmacs. It has strong recommendations from people working at Sun, where it is already becoming widespread. Documentation is better than git's, and much better for the new user. It's developed by vcs pros.
Bazaar is close to Mercurial, for similar reasons (s/Sun/Canonical/). However, I give Mercurial the edge because it is being developed by people who develop vcses for their own sake, while Canonical has demonstrated that their interest in vcses is instrumental to their development business. Nothing wrong with that per se, but I think that dvcses have a long way to go to reach maturity (viz Darcs's "theory of patches" approach and its innovative and addictive UI not yet copied by any of the other main contenders). I think it's worth going with Mercurial for the possibility of picking up on the "next next" generation early. While the whole point of bzr is to be to tla as svn is to cvs. :-)
I should remark that bzr's diffs are currently the best in the business. See my reply to Edward Elhauge and also Bram Cohen's blog http://bramcohen.livejournal.com/37690.html. This advantage probably won't last long, though---git and Mercurial both have their diff commands well-modularized, it won't be hard to add.
Re some vcses that IMO won't fly:
Darcs, although very interesting as a radical departure from the other dvcses, is IMO not ready for prime time yet. Development is somewhat slowed by being written in Haskell, which makes it hard for most users to contribute directly. It also has some really dire performance problems that show up in ordinary usage for a non-negligible fraction of projects.
The Arch 1 family (arx, tla, baz) is a non-starter. It's very usable, but for future development, it's orphaned. The main author, Tom Lord, is once again being a radical innovator, movint on to Arch 2. But Arch 2 (also known as "revc") is not ready for "real work" yet, it may not even be self-hosting at this point. In any case, Tom is not currently able to push development very actively.
There are a couple of others out there, but I think the main contenders are Bazaar, git, and Mercurial. IMO any of them will do.
Bazaar is a distributed version control system. This is really the
crucial different between centralized systems such as Subversion and
CVS, and it's the main draw for wanting to switch.
It also means that at the present time there's very little difference between git, Mercurial, and Bazaar in use. The real difference is in the goals of the maintainers, namely "keeping Linus happy", "making the best possible dvcs", and "what we use at work." All of these have their advantages.
Everything that Barry wrote that I've cut out I agree with, strongly.
One more thing. If we move to Bazaar, I would host the branches on
Launchpad.net, which -- full disclosure again -- is developed,
managed, and paid for by my employer. Why Launchpad? Because it's
convenient, I have insiders I can bug, and because it already
supports hosted Bazaar branches.
IMO, this is an important advantage to Bazaar. Similarly, the Debian project sponsors a Mercurial host on Alioth, which I would imagine is pretty professionally run. Barry being an insider at Launchpad is a good thing, though. Does use of Launchpad imply access to the patch queue manager, too? Or is that Canonical-only? (Not a problem if it is Canonical-only, but it's a nice-to-have feature!)
Let me emphasis that Canonical is in no way driving this.
Good. AFAICT, Canonical is a big business, it behaves like a big business, but it talks like a charity. Nothing wrong with the first two, but the third confuses me. I'd recommend keeping arms' length.
I personally think Bazaar+Launchpad will make some of our lives easier,
+1 on that. I've now done merges of multi-megabyte patches with both Darcs and git. It's thinkable. Doing it with CVS or Subversion no longer is. (That would apply to bazaar, too, I'm sure, though I have no experience with it.)
One caveat: as the dvcs proponents are always pointing out, it's not necessary to actually use them in a distributed fashion. In fact it's *easy* to just drop them in to the same old workflow. This gives a perceptible improvement for insiders, but in open source you can get lot more! I hope, Barry, that you will allocate some time to reorganizing the Mailman workflow to encourage participation from third parties (eg, Fil, the MHonArc patch, etc).