Success stories

Subversion to Mercurial

I was a Python developer in a company that developed quite a big web application. At some point in time I stumbled upon a DVCS (I'll skip the story about my introduction to Bazaar, Mercurial, and Git) and proposed to switch to it (as I learned from my own projects that DVCS is better than CVCS). My proposition was rejected with the rationale that there was "no time to do that, as we're going to launch the site in the near future."

Our launch was somewhat delayed and in January we had a lot of troubles with SVN: there were 3 main branches - stable, testing, and unstable - and we could merge fixes between them with svnmerge.py. It was really painful as you would have to restart a merge from scratch if someone committed to a branch - and that was pretty often the case for our (quite big) command. Additionally, there were a lot of commits for debug purposes, commits closing tickets with a following "small fix for previous commit," and so on.

This often resulted in a broken repository. And in January of 2008 one of my colleagues read about and played a bit with distributed version control systems and was very excited about them. We decided to try to convince our managers to switch again and we succeeded! This required two (or three) weeks of conversations with long emails, describing all of the advantages of DVCS.

We eventually decided to switch to Mercurial. The two other competitors were Bazaar - whose slow speed knocked it out of the competition almost from start - and Git - with its bad UI, poor Windows support, and lack of a TortoiseHG-style utility (which helped us to educate designers).

Some time was required to perform the switch (actually we have switched after the launch), most of which was spent waiting for action. After the switch a week was required to teach our developers and designers to use Mercurial properly. One of our test engineers told me after the first week (when everyone was studying) that the number of regressions had already lowered fivefold.

Our setup wasn't a plain centralized repository with all developers pushing to it, but instead we were split into teams consisting of 3-4 members where only team leaders had rights to push to main repo. Other developers had to send changesets by using "hg serve" (the leader could then pull from their repos) or by using our hacked version of patchbomb which sent both plain patches and bundles together (we used this because some of the leaders were using Windows and dealing with bundles was easier for them, while plain text was easier to review). Then a basic review of changes was performed by a leader and if he didn't notice anything wrong, the changesets were pushed to server.

In this case the main repo received only finished features, often reviewed by some of the business people, as we had another pretty thing: personal dev servers. Every developer could clone any repo to his homedir and a subdomain with his username (http://username.dev.example.com/) was served by an instance of Apache using codebase from this repo (pointed to it through usage of ~/htdocs/.htaccess). This allowed testing changes on a big database (nightly from public server) and demonstrating features to business people.

Of course, we additionally got all of Mercurial's goodies: the ability to develop offline, the ability to develop features with other developer without bothering the main repo, cheap branches (how painful they were with SVN!), fast annotation and backout (I spent a lot less time on regression fixes) and overall great performance (I haven't mentioned mq, but IIRC I was the only one using it).

The switch to Mercurial was definitely the right decision and our managers praised it after a month of work.