Using Mercurial with Virtual Machines

Ryan Van Slooten — Thu, 21 Jan 2010 21:31:19 GMT

Recently I have started using Mercurial (also known as ‘hg’ which is the command line tool) for source control management (also known as version control system) for some of my projects. Most of the projects I deal with use Subversion which is sufficient for most needs. My first exposure to distributed source control management was Linus Torvald’s presentation on git at Google. In a nutshell, he rails on CVS (his initial intention was to design a system as “What Would CVS Never Do” [WWCCVSND] and he considers tarballs and patches as superior to CVS) and also sees Subversion as “the most pointless project ever started.”

Popular Open Source Distributed SCMs / DVCSs

There are several popular open source distributed SCMs/DVCSs include Darcs, Bazaar, Mercurial, and Git. Currently, it seems that Git is the most “popular” of the bunch (at least in the blogs and tweets that I’ve seen) due to the github and projects like the Linux kernel and others. A quick comparison from stackoverflow also verifies popularity in terms of the number of tags related to the respective systems (I listed the main tag only although there were quite a few subtags for Git and Mercurial):

Why Mercurial?

I believe Mercurial, Git, and other DVCSs will work great for most cases. There are several analyses on the web with varying results, but the all of the available open source DVCSs are strengths and weaknesses and are capable. That being said, there are several reasons why Mercurial is a good choice.

1. Portability

Mercurial is written primarily in Python with small portions written in C for speed. This makes it extremely portable to almost every architecture. While Git is available on POSIX systems, there are basically two Windows versions with one requiring Cygwin and the other is called msysGit.

2. TortoiseHG

Another reason is TortoiseHg which is a shell extension primarily for Windows, although there is a Gnome/Nautilus CLI extension and a Mac OS X version is in the works. TortoiseHg is written with gtk/tkinter so that makes it easier to port to other systems than TortoiseSVN or TortoiseGit (both are Windows only) although I wish TortoiseHg used wxPython instead. I’ve also used QGit and GitGUI the experience with Tortoise* is generally better in my opinion.

3. “Smart” HTTP

Mercurial has built-in “smart” HTTP which leads to more efficient transfer when using HTTP. There is discussion of Git implementing smart HTTP. The reason HTTP is important is it is a universal common denominator. Some corporations block the ports used for native git or git+ssh access. Also, I have done work with people in foreign countries where the native protocols didn’t work, or we could use ssh, and HTTP was the only option.

'hg serve' is an extremely easy way to start the Mercurial internal web server. As one person noted:

I chose Mercurial since it feels clean and elegant -- I was put off by the shell/Perl/Ruby scripts I got with Git. Try taking a peek at the git-instaweb.sh file if you want to know what I mean: it is a shell script which generates a Ruby script, which I think runs a webserver. The shell script generates another shell script to launch the first Ruby script. There is also a bit of Perl, for good measure.

4. Google support

Google officially supported Mercurial for project hosting in Google Code on Friday, April 24, 2009. Google also released a report on their internal DVCS analysis with the following summary:

Summary

In terms of implementation effort, Mercurial has a clear advantage due to its efficient HTTP transport protocol.

In terms of features, Git is more powerful, but this tends to be offset by it being more complicated to use.

I personally doubt Google’s support of Mercurial will sway the DVCS competition significantly towards Mercurial as I believe Git is powerful, robust, and here-to-stay. Google’s support does give significant credence to Mercurial though. I expect improvement in both Git and Mercurial in the future which will probably blur the lines even more.

Using Mercurial with VMs

The primary benefit of using a DVCS with virtual machines is that the VM does not need to be connected to the outside world but instead only needs access to the host. Most of my VMs use “Host only” networking which allows the VM to connect to the host, but not the outside network or Internet. Thanks to the easy Mercurial built-in web server, it is easy to share a repository from the host to the VM.

Step 1: Create or Clone repository on Host

For example, if we take the 'hello' repository from the Mercurial tutorial, we can clone an existing repository on the host environment:

Step 2: Starting the Mercurial Web Server

You can either start the web server by using 'hg serve' from the repository directory, or use TortoiseHg Web Server:

If you are going to be pushing repository changes from the VM back using HTTP, then don’t forget to enable pushing via HTTP in the host '$(repository)/.hg/hgrc' file:

[web]
allow_push = *
push_ssl = false

Step 3: Cloning the Repository from the VM

This step is similar to Step 1, except change the source to the repository on the host, e.g. :8000/">http://<yourmachinename>:8000/.

Then modify the source as necessary on the VM and commit your changes to the local repository.

Step 4 – Option A: Pushing Changes back to the Host

Once you are ready, you can push your changes back to the repository on the host:

If you get a failure, then check the [web] settings in Step 2 and restart the web server if you change the 'hgrc' file.

Step 4 – Option B: Pulling the Changes back to the Host

Alternatively, you could start the Mercurial Web Server on the VM and pull the changes from the host. This just requires you to start the web server on the VM, and also make sure the specified port, e.g. 8000, is not used by another web server and is open. You can add a sync alias for the VM(s) which makes it easy to switch to different sources/repositories with the Repository Explorer:

Conclusion

It is easy to use Mercurial, or Git for that matter, in combination with development on virtual machines to allow developers to commit and experience a real SCM/VCS experience.