I decided to give the distributed version control system Mercurial a shot for my personal development projects. I was hearing rave reviews about Mercurial from fellow TechRepublic bloggers Chip Camden and Chad Perrin, but I didn't have a super-pressing need for it. (Note: I am using a Windows PC, and at the risk of losing my elite status in the Geek Kingdom, I typically prefer GUI tools to command line tools for my desktop work.)
I downloaded and installed the free TortoiseHg application, which enables you to have Mercurial repositories and perform commits, merges, etc. against them. TortoiseHg allows for the synchronization to other Mercurial servers; the application also adds itself to the Windows shell so that you can use it in context menus in Windows Explorer.
To give myself the ability to use version control within Visual Studio, I installed VisualHG.
To get the ability to work with others (in theory), publish code, etc., I signed up for a free account (it's free for five or less users) with the recommended Bitbucket. I made a test repository in Bitbucket as well. This entire process took me less than five minutes and was insanely pleasant (particularly Bitbucket's easy registration).
Getting to work
Once everything was installed, I used TortoiseHg's Repository Explorer to set up a connection to my Bitbucket repository. I had a new project that needed to go under source control, so I navigated to the parent directory in Explorer, and used the TortoiseHg context menus to turn the project into a Mercurial repository. I performed an initial commit, and everything looked fine. I opened it up in Visual Studio, made some changes, and performed another commit. This is where it started to get a little painful.
I went to Bitbucket, and I did not see my changes, so I panicked. I am so used to TFS and other centrally managed version control systems that I forgot that that a Mercurial commit is purely local. All I needed to do was perform a Synchronization with TortoiseHg to upload my changes. Once I did that, I saw my work in Bitbucket. As I adjust to Mercurial's way of handling things, I know that I will be very happy with this scenario. The VisualHG tools work just fine doing what they need to do.
My only pain point at this stage is that I have a pile of projects that are still under TFS's version control. I need to move those projects to Mercurial, but in the meantime, I made TFS my source control plugin for Visual Studio. I will manage my Mercurial projects with TortoiseHg until I fully make the cutover to Mercurial.
Thumbs up for this setup
I am loving this setup; it is so much easier than putting together a TFS project it isn't funny. But I'm not saying that it's perfect. TortoiseHg has a very rough UI that is not intuitive or helpful. Another consideration is that neither Mercurial nor Bitbucket are as enterprise ready as TFS in terms of being able to get metrics, having built-in unit testing and automated builds, tying work items directly to check-ins, and so on. If I were in a big, corporate development environment where these features were necessary, I would either stick with TFS, or add a few layers of other applications to get the needed functionality.
But for my needs on personal development projects, I could not be happier. I am positively delighted at the ease of use, simplicity, and reliability of the combination, and I know that if I were to add a couple more people to my development, that we'd all be very happy. I like Mercurial's workflow a lot — it's just a matter of rewiring my brain to think like it does. I would like to see TortoiseHg continue to improve. Bitbucket is a great site — it's extremely easy to use, and it has some nice tools.
I give the combination of Bitbucket, TortoiseHg, and VisualHG an unqualified thumbs up. It will take you less than 10 minutes to find out if it is for you, and that is 10 minutes that I doubt you will regret spending.More about Mercurial on TechRepublic: Secure Mercurial and BitBucket for your development projects and A development workflow for Mercurial.
J.JaDisclosure of Justin's industry affiliations: Justin James has a contract with Spiceworks to write product buying guides; he has a contract with OpenAmplify, which is owned by Hapax, to write a series of blogs, tutorials, and articles; and he has a contract with OutSystems to write articles, sample code, etc.
Justin James is the Lead Architect for Conigent.