Let's get in touch

The pains of switching to Mercurial

Quite some time ago now, we started switching our projects from Subversion to Mercurial. Why you may ask? After reading Joel Spolsky’s introduction to Mercurial (http://hginit.com/), being the hipsters that we are, we simply had to try it out 🙂

This post won’t be about the advantages and disadvantages of distributed source control systems. It will be about setting up a source control environment based on Mercurial.

We wanted two things – integration with Eclipse and a simple method of creating/using remote Mercurial repositories which would be considered central repositories for our projects. The integration with Eclipse part wasn’t a problem – we use MercurialEclipse which works fine. Since the plug-in doesn’t enable you to do everything Mercurial-related we use it together with the standard Mercurial command-line utility.

The other thing we wanted was a practical way of creating remote Mercurial repositories and managing access rights. Since we have an online Ubuntu server we chose to use mercurial-server. Mercurial-server is a set of scripts which enables using and creating remote repositories, SSH public key authentication and fine grained per-user-per-repository access control. All communication goes through SSH.

Since we mainly use Windows for development, the first thought was to use PuTTY (actually Plink) for the communication between Mercurial and mercurial-server. The instructions on how to configure mercurial to use PuTTY can be found on the official site. After trying everything we couldn’t get it to work. After quite a lot of hours of fiddling – we found the problem. PuTTY’s saved sessions. If you’re like me, you save the connection setting for myserver.com under the session name myserver.com 🙂 Big mistake, my friend… It turns out the saved sessions are known throughout the PuTTY suite, Plink included. This is normally a very convenient thing – you can type ‘plink sessionname‘ and plink will use all the connection parameters from PuTTY’s saved session – no need to specify everything again. The problem with mercurial-server is that you have to connect via SSH as ‘hg’. If the server name is the same as the session name, Plink will override the connection parameters provided by Mercurial and will use those from the saved session (which is probably configured to use another username for connection and thus mercurial-server won’t respond). Having sorted this out – Mercurial worked fine.

And by fine I mean really slow 🙂 The initial cloning of a 60-something megabyte repository took more than 20 minutes. The problem turned out to be the SSH client – PuTTY in particular. We switched to cygwin + OpenSSH and the initial cloning time went down to 5 or 6 minutes which is much better. Of course this is nowhere near as fast as cloning the repository on a Linux system – it takes about a minute there 🙂

If you have some ideas on how to increase the communication speed on a Windows machine further, I would love to hear.

Leave your comment
  • doorman

    what about switching to a *NIX/BSD or one of its derivatives (read GNU/Linux or MacOS)?

    Even if your development is Windows-centric, nowadays you have plenty of options. For one, there’s Wine (http://www.winehq.org/) which offers very good integration of Windows apps and has been proven to work with an amount of applications (take a look at the “Database” on the site).

    My favourite is, however, virtualisation. kVM, QEMU and VirtualBox, just to name a few, have very advanced features because of which you might even forget you’re actually on a non-Windows machine. Moreover, with today’s explosion of Cloud computing, people are working to improve them at a crazy pace.

    Just my two cents, but I hope I got you thinking at least.

    Merry Christmas & happy New Year!

  • fressner

    Because emulators/virtualization are a pain in the ass and because Starcraft 2 doesn’t run on non-windows machines 🙂

We use cookies to help us optimize the website experience. Okay

Learn more about our privacy policy.