[pypy-dev] Switching to a distributed version control system

[Dirkjan Ochtman]

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

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