Every time I think I got all the tools I need and I have a killer setup, something comes along that makes me question it all. I am referring to mercurial. For some reason, I have just heard of mercurial from TekPub. I don’t know why I never heard of it before. Probably because I wasn’t looking to replace subversion as my trusted source control.
I like the subversion and it does the job for me, but after watching tekpub’s videos, I instantly realized the power of mercurial and why I must have it. So I went ahead and converted my source control for dartfiles to Hg (hg is the chemical symbol for mercury in the periodic table). I was actually surprised by how easy the move went.
Here is what I did:
- Downloaded and installed TortoiseHg
- Exported my subversion project to a new folder
- Created a Mercurial repository at the new folder where I exported the code in step 2
- Edited the ignore file (.hgignore) in notepad and added the following (which I found somewhere on stackoverflow)
- Committed the repository
<span class="rem"># Ignore file for Visual Studio 2008</span>
<span class="rem"># use glob syntax</span>
<span class="rem"># Ignore Visual Studio 2008 files</span>
That’s all I had to do to setup mercurial.
You are probably wondering – where is the source control server and where are you committing too. This is the part that is different than what I have been used to with subversion. Obviously if you are using git or similar distributed SCM then you are familiar with this concept. Mercurial stores all your source code changes and tracking locally right in your folder inside a .hg subfolder (similar to .svn folders but not exactly). When you commit you are just committing to your local repository. This is pretty cool because it lets you commit locally, roll back to a different time, branch and do all kind of cool things without having to deal with a server.
Imagine you are working on feature 1 then you get an email for an urgent bug (lets’ call it bug 2). You can’t really work on it because feature 1 is not complete and the code won’t compile and things could get messy. You want to fix the bug but you don’t want to lose all the work you put into feature 1 and you are note ready to deploy. With mercurial, it’s pretty easy to handle this situation. Simply go back to a point in your history before you started working on feature 1, create a new branch for bug 2, fix it then commit and push it, you can then deploy this version and then come back and merge the bug 2 branch with your feature 1 branch and continue working on feature 1.
I probably didn’t do a good job explaining this scenario but hopefully you will at least get an idea of what I am talking about. If not then head over to http://mercurial.selenic.com/ and take a look at their great documentation.
In most cases, you will want to setup a remote repository so you can “push” code to it. “Pushing” is another concept that was new to me. Basically, you commit locally and you push remotely (or centrally). This gives you the flexibility to commit all day long every time you make a change and only when the code is ready and stable you “push” it to the remote repository where other developers can get to it. I setup my remote repository at bitbucket – http://bitbucket.org/ – they have a free account and some very reasonable pricing. If you are working on open source/public code, you can always use Google code or codeplex; they both support mercurial.
Here are the steps
- Created an account at bitbucket.
- Setup TortoiseHg to talk with the remote repository (right-click > TortoiseHg > Repository Settings)
- Pushed my code to the remote server
I use TeamCity as my build server (blog post). Once everything was working nicely, I had to get TeamCity to work with the new SCM. This was pretty easy as well. I basically removed my old SVN root from my TeamCity project and added a new root to point to mercurial
To make this work, you have to install mercurial on the server. Get it from http://mercurial.selenic.com/downloads/
Initially, I had a problem with the HG command path and it was giving me some weird error like failed to create process or something like that (I can’t remember). It turned out the problem was that TeamCity couldn’t deal with spaces in the path. The install location was “c:\Program Files (x86)\hg” so I just moved it to c:\hg and everything worked.
Once everything was working well and after working for a few hours, doing a few commits and one deployment, I realized the power of mercurial. Just take a look at my repository history and you might grasp the awesomeness that is mercurial.