Grauw’s blog

Saving time with Mercurial

January 5th, 2010

At work, we use SVN. As a Mercurial convert, I’d like to share three examples that I encountered today where the Mercurial distributed revision control system could’ve saved me time and headaches.

1. Reduced risk of breaking the trunk

Today I left an hour later than I liked to, because I had checked in some changes which turned out to be broken. Since Wednesday is my day off, I could not fix the problem first thing the next morning, and leaving it the way it was would be a big inconvenience to my colleagues.

The underlying problem is that with SVN, every time you check in it ends up in the shared repository. Because the trunk needs to be kept in a working state, this requires a lot of testing effort for every check-in. In practice, this testing often doesn’t happen thoroughly enough, and sometimes a broken change slips through.

With Mercurial, you commit your changes to a local repository that is not shared, and every once in a while you synchronise your local repository with the shared (trunk) repository. This relieves you of a lot of testing effort, as you only need to test thoroughly before sharing your changes with the main repository, rather than for each individual check-in.

In this case after finding that there still were some issues, I could’ve simply gone home without synchronising my latest set of changes with the server.

2. Narrowing down the source of problems

Usually I make small incremental commits. By doing this I keep the amount of uncommitted changes low, so that I can easily compare my current code with the last working state in the version control system.

At a certain point though I was working on a big change, and I had to hold back on committing intermediate results because I knew it wasn’t fully functional yet, after all we can’t have the trunk in a broken state. Yet because of this, every time something did not work any more it was very hard to find what changes exactly caused it.

Since with Mercurial commits are not shared with the main repository until you tell it to, I could’ve continued to do small commits, and saved myself a lot of debugging headaches.

3. Checking in the parts that are ready

One thing I always miss terribly when working with SVN is the ability to commit partial changes. Now admittedly this is strictly speaking not a Mercurial feature. Nevertheless TortoiseHg, the Windows and Linux shell extension for Mercurial, is the only tool I know of that has this feature.

Often you have some changes that you would like to commit, but you also have some other changes that are not ready yet. A pretty tedious process usually follows: you make copies of the changed files, revert the files, compare them with the copies and copy over the changes that you want to commit. Then you commit those changes and copy back the original files.

With TortoiseHg this is all much simpler. In the commit window you can activate and deactivate individual changes within files, and thus only select the changes that you want to commit. This would have been convenient when I took a break from refactoring to fix a bug that a colleague reported.

In summary, where Mercurial really outshines SVN is working on several things at once and making small, manageable commits. It also reduces testing and debugging overhead, and lessens the risk of broken changes ending up on the trunk.

Sounds compelling to me! :)



Re: Saving time with Mercurial by FiXato at 2010-02-12 23:55

Most of the problems you have described, can be ‘solved’ or at least avoided by developing your features on ‘topic branches’.
That way you can keep making atomic commits, even keeping things synchronised with an external server, without the trunk being affected. Once everything is done and ready to be deployed, you can try synching it back into the trunk.
Of course, branching isn’t that nice in SVN as it is in Git (or I suppose also Mercurial), but it could help with some of the issues.

As for the partial commits, I thought that TortoiseSVN also had that support?
The third answer at seems to describe the workflow for that.

Again, probably not as clean as with Git or Mercurial.

Finally, why do you keep working solely with SVN at work? Isn’t there some bridging possibility for Mercurial (something like Git-SVN


Re: Saving time with Mercurial by Grauw at 2010-02-13 00:22

Hey FiXato,

It’s not so much about whether SVN can or can not technically do it, the concepts are similar after all, but whether it actually supports the workflow of the developer, whether it is easy enough to be useful. SVN branches are like ‘named branches’ in Mercurial. That is, something that you could use for say a release branch, but would usually rather avoid in favour of the more lightweight branching. Like just copying your project, or making good use of the local branch.

The implicit local branch that you automatically get with your local repository is the nicest, every commit you make is on a separate branch until you push. It does not need to be explicitly created (unlike SVN), and it allows you to deal with branching after-the-fact (unlike SVN). This is where the big difference lies, and this is so very useful, especially when doing small commits…

Let me ask, how often do you branch with SVN? Once a month, or once a week at most? With Mercurial I branch at least once a day, usually several times more. “Commit early, commit often” only really works with a DVCS.

Re. partial commits, TortoiseSVN does not support this, the stackoverflow page describes what you have to do if you don’t have this partial commits feature (i.e. the bothersome process with backing up, diffing/modifying, committing and restoring files). You should try TortoiseHg sometime! :)

And as for bridging, actually I do nowadays work with Mercurial on top of SVN. However, it is not for the faint of heart. It forces you to rebase all the time, and modifies history extensively. I already almost lost my history once, and that is the exact opposite of what a version control system is supposed to do :). I see on your link that git-svn has the same problems. I would not recommend it to anyone who doesn’t have an advanced level of understanding of Mercurial.