Hi there, I'm a Mercurial committer who also listens in on #pypy some time. I remember we had a discussion about this subject with Armin and Michael a few weeks ago, where it was stated that the conversion process would likely be scary and that SVN was working alright for this project... Jacob Hallén wrote:
to be a guru on bzr by now. Hg seems to be a little more tedious in its command set than the other two. Git used to be rather obscure, but is these
I don't know why hg seems tedious. hg's commands have been designed to be rather a lot like SVN where this is possible.
days very straight forward to use. Git and bzr have very good visualization tools for showing the splitting and merging of branches. Git seems to be best at showing exactly what changed between 2 versions of the code (even 2 versions that are not on the same subtree).
The strongest argument in favour of git seems to me to be the rebase feature, which allows one to make a branch for a new feature, work on
hg has also has fairly good visualization tools. We have a command-line graph in the form of the glog extension, and in the upcoming release we will feature a canvas-based graph in the included web interface: http://hg.xavamedia.nl/mercurial/crew/graph/ In addition, there are a TortoiseHG tool for Windows which also provides some integration/GUI on Linux (PyGTK-based). the branch and then update the base of the branch to branch off at a later point in time. I haven't identified this feature in hg and bzr, but then I haven't read all the documentation in detail. In the next release, hg will come with a rebase extension. hg also comes with the very powerful mq extension, which allows developers to keep versioned patch queues around, which can be detached from the repo and distributed separately (and which allows for easily updating, splitting and merging of in-development patches/changesets).
The one feature of svn that we would miss is the inclusion of foreign version controlled trees, like we do with the pylib tree. We would have to do this in a different way than before, since none of the systems have this feature. I'm not sure it makes sense to have the close svn coupling between the projects any more, in any case.
Mercurial has the forest extension, which does this for OpenJDK, and NetBeans, I think. In fact, I think Mercurial is of the DVCS's the one with the most large projects: OpenJDK, NetBeans and Mozilla all use hg.
There is of course the hooks that send mail and blurb in IRC, but all 3 systems seem to have at least as powerful hooks as svn.
In addition, hg has a very easy-to-use extension model, allowing Python developers to easily extend the functionality available in the tool. In fairness, Mercurial's support for branches is a little different than most people are used to; either people can use separate clones for branches (which use hardlinks, so they aren't too expensive), or changesets get committed to a branch name, but since history in hg is immutable (I think this is largely true for any DVCS, but hg can be a little more strict about it), this means branches cannot currently be deleted. Branches that have been merged back into another branch can be kept out of command output, though. Anyway, I'd like to help out with the conversion and infrastructure, should PyPy chose hg. Cheers, Dirkjan