A Dive Into Distributed Source Control

My team has recently made the switch from Visual Source Safe to Mercurial.  Here are some noteworthy points about this adventure:

Ability to be choosey about when to release your code

How often has this happened to your team: the source builds, and all the tests pass, so you commit your changes at the end of the day.  The next morning you’re running a little behind, and you’re greeted with the stink-eye by your colleagues.  You only half way implemented the log-in page so everyone is locked out of the application…until you fix it.  With distributed source control this problem goes away. 

Using distributed source control I can commit locally any time I want without affecting the rest of the team.  Meanwhile, I still get the ability to punt and rollback changes if and when I get too far down the wrong path. 

A nice side effect of a clean shared repository is that it’s ship-able at almost any time.

Effortless reverts/rollbacks

As soon as I’ve completed a decent chunk of work (a passing unit test or a layout change) I commit.  Commits happen in the blink of an eye, so there’s no disruption to my workflow.  Also, every time I check work in, I tag it with a 4-6 word description of what I just did.  Now I have a really nice trail of comments to show me where I’ve been.

Since the change sets are small, those commit comments become much more meaningful.  Other developers can look through the change log and pick out interesting looking changes to learn from.

Since the repository is on a local disk, reverting or rolling back changes takes one or two seconds.  Because of the speed and frictionless experience, it makes you feel much freer about using the features.  Subversion/TFS/et. al. all have the ability to revert, but it’s a process and ceremony that takes so much time that I’d rather work around it.

Safety

If you’re using distributed source control the way it was intended (small commits, pushed to a shared repository) there is almost no way to lose code.  The biggest feeling of safety I get over using traditional SCM’s is when I’m merging.  Using Subversion or TFS, if I goof a merge then my working copy is in a broken state until I rectify it.  If I’m using a distributed system and I fat finger a merge, I’m just a revert command and one second away from my pre-merged code.  After my revert I can take a deep breath and try that merge again.

Easy branching/merging

This is the one thing that everyone talks about, and it is true.  Branching and merging is effortless once you’ve unlearned what subversion and other central-control systems have taught you about it.  I found www.hginit.com to be a great way to understand the essence of distributed source control usage.

Easy integration with TeamCity

For the first time in my career, I am the guy in charge of the continuous integration server.  I was a bit daunted at the task, but TeamCity made it simple.  TeamCity’s support of Mercurial is first class and makes it simple to pull the code and build it.

GUI Tools for learning

When I first started getting a feel for distributed source control I leaned heavily on TortoiseHG.  It was a great way to visualize branching/merging and some of the other new concepts that I needed to learn.  Now that I’m a little more seasoned, I get a lot less workflow fiction by relying on the CLI.

VisualHG is a Visual Studio plugin that is a lot of help.  The primary interest I have in VisualHG is that it tracks all of the actions I take in the IDE such as adds/removes/and renames.  These actions otherwise require me to remember to make Mercurial aware of the action by using the ‘addremove’ command. 

Corrupted my repository

One word of caution: do not inadvertently touch the local repository files.  TortoiseHG by default makes copies of files that you revert.  I hadn’t noticed this until later, so I wanted to clean up all of those un-needed files.  By doing a search on the parent folder of my repository I found _all_ of those files and deleted them – including the ones that were in the repository.  Dumb.  Mercurial was very kind and told me there was a problem – and what revision I could revert back to.  To get out of that pickle, I pulled the latest version of the shared repository and merged my working copy into that.  I lost a few changesets from my local repository – but all my code was still safe from my working copy. 

Why Mercurial over Git?

A couple reasons, most of which are based on gut feel.

1) Git commands seem esoteric compared to Mercurial.  Mercurial’s commands just feel natural and like something I can easily remember.

2) Everyone raved about Mercurials Windows support, along with excellent GUI tools.  Meanwhile I heard only bad things about Git’s Windows support.

3) Codeplex began to support Mercurial, so there was an extra confidence push that raised the comfort level.

4) Martin Fowler’s article on source control management tools didn’t hurt.

5) I have to worry about line endings?  This was actually a big turn-off.

6) Git has a strong community following, but after poking around for Mercurial resources I found solid community backing there as well.

Conclusion: What you’ve been told is true, distributed source control systems are a much more natural fit than traditional SCMs.  It’s really quite difficult to explain the feeling of freedom I get when using source control that I feel works with me…but just trust me: it’s a good thing.