Hex, Bugs and More Physics | Emre S. Tasci

I’ve been using SVN for revision control system for some time. I certainly benefited from it to organize or fall-back to a stable version (“the good old times”) when I was in trouble while I was computing solo but there were two things that always upset me while using it:

• Commiting meant publishing: This issue might be worked around when you have your trunk (we actually have the trunk for the ‘most recent’ status and a ‘released’ branch for the tested and stable programs of that trunk) and each of the developers play in their branches until it looks OK and hence merge it to trunk (and hopefully eventually make it to the ‘released’ branch), but the problem is, most of the time I’m in the middle of the coding process (in my branch) and it would be nice if I didn’t affect the main repository everytime I made a commit (it’s really not very nice) – in other words, even in my branch I would like to save while not making them available. The answer to this lies of course in distributed revision control systems (dvcs).
• Merging: Merging is hell in SVN when you have many developers. Been there, suffered that.

I had heard of git and bazaar but -for some reasons I don’t know why- never had taken the step to give them a try. Very recently, in a scientific gathering, one of the participants suggested me to use mercurial. The interesting thing about this is, he was suggesting it as a means to enable an “undo” option for a -scientifing- refinement program which has the tendency to update your files in according to the changes you applied. I know this sounds natural but when you tried some method and it didn’t worked, you couldn’t go just one step back and use a different method – you have to start from scratch with your initial input file and apply the methods so far but the last consecutively over again. So, my friend was actually recommending me to use a revision control system for the work files (which can be done perfectly well via SVN, by the way) and he happened to be using mercurial. He suggested to check this website by Joel Spolsky (http://hginit.com/) to get it going and the website is very intriguing, indeed. So I have been running some tests to get my feet wet and it was going so well until I found that the log command didn’t reveal the list of the changes made upon the files per changeset (‘revision’ in terms of SVN). I searched and searched and at the end I found the solution on hg tip (http://hgtip.com/tips/advanced/2010-01-15-styling-mercurials-cli/) website by Steve Losh. His ‘Nice Log’ script was exactly what I was looking for plus some additional effective logging templates.

I don’t think for our big project I can make the switch from SVN to Mercurial, but from now on, I’ll be ‘hg init’ing instead of ‘svnadmin create’ing for the projects to come.