[pypy-dev] Mercurial workflow

Jacob Hallén jacob at openend.se
Tue Dec 14 18:04:06 CET 2010

Hi folks,

now that the switch to Mercurial has happened, people are discovering that 
their Subversion workflow habits don't quite work. This is because Mercurial 
has a distributed philosophy, inlike svn which has the concept of the holy 
central server where all operations take place.

In Mercurial, you do all the important operations in your local repository. If 
you have a central node (which is not strictly necessary), you just push ready 
made change sets to it. Any conflict resolving has already been done on your 
local machine.

This means that it is very convenient to have at least 2 repositories locally 
(this takes hadly any extra space, since unchanged files are hard linked to be 
the same file in each repository).

You keep one repository as a staging area to which you pull changes from the 
central server (or other peoples repositories) and to which you pull changes 
from your other local repositories. It is here you resolve any merge conflicts 
and it is from here you do pushes of new versions to the central pypy server 
on bitbucket.

For every idea you have, you clone your repository and do the work for the 
idea in the clone. If you need to collaborate with someone else you 
synchronize your repo with their repo without going through the central 
server. Branching is a concept that is separated from the repository clones 
and it is just as good an idea to make branches for new features as it was in 

When you work on an idea you should keep in mind that it is an extremely fast 
operation to commit your work. You can do it for a number of various reasons - 
whenever you have made a set of changes that you feel belong together, if your 
machine is flakey and you want to have a backup copy somewhere else or if you 
want to continue the work on a different machine. I sometimes program in bed, 
and it is very simple to do a pull from my workstation to my laptop.

The new workflow will make the detailed changes less visible to others, since 
you commit work to the central server in fewer and bigger chunks. This means 
that there will be fewer "oops, I misspelled this" and more of a higher level 
view of what is being developed.

I hope this helps getting your minds around how to work with Mercurial. I hope 
you will discover that the way it is different from svn will improve your work 
environment and your work habits. It has done so for me.


More information about the Pypy-dev mailing list