Distributed verison control systems are gaining in usage and popularity, but many organisations still use traditional centralised VCSs like Subversion and Visual Source Safe. Recently I've been using a hybrid setup and getting many of the benefits of a DVCS without needing to move the whole team to a new VCS platform.
When I started with VSoft a few months back my first chunk of work was to create Mercurial actions for the upcoming FinalBuilder 7. It was the first time I'd used a DVCS and after the initial shock I became quite fond of it.
Internally we use a CVCS - Surround SCM. If you've never used Surround you can think of it as VSS done right. It uses similar concepts and abstractions but without all the pain and frustration. We're considering moving to a DVCS but haven't yet worked out if the increased flexibility is worth the extra overhead for our relatively small dev team.
After getting to know Mercurial though, I knew what I was missing out on. Primarily for me that was version control of my local changes. This is becoming more important as FinalBulder 7 gets closer to completion and breaking the build becomes a bigger deal. I also like being able to easily clone and sync my repositories locally as a basic backup strategy.
The setup I've come up with couldn't be simpler. If I'm going to work on a VS.NET solution I will:
- check out the solution from Surround
- hg init the solution directory to create a repository
- hg commit -A which adds/removes all file changes to the repository
- work locally, committing whenever I feel like it
- when the solution is in a state where it won't break the build, check it in to Surround
To make things easier I've set up this alias in my Mercurial.ini:
[alias]
cam = commit -A -m
So to commit I just hg cam "commit message".
Recently I started checking my .hg directory into Surround as well. That allows me to maintain the history of all my local commits, without cluttering up the Surround check-in logs.
Caveats
There's some things to be aware of when using a hyrbid system like this. While you could still use Mercurial for merging work from different developers it is much more complex than in a pure DVCS setup. I'll leave it to you to work out the details: it's not something I plan on ever doing.
If you're checking your .hg folder in to your CVCS you need to be careful that it doesn't become corrupted through concurrent updates/merging. Of course if it does become corrupted you don't lose much by deleting and recreating it, because the check-in history for your major changes is in the CVCS's check-in logs.
Other uses for Mercurial
Because Mercurial repositories are so easy to create I've started using them for all sorts of things. For example, at home I have a perl script that runs nightly and exports the contents of my Wordpress blogs to XML. Previously I included the date in the filename and ended up with (literally) hundreds of files in my backup directory.
Now I've set up a Mercurial repository, removed the date component from the filename and have my backup script commit after it downloads the latest version. The directory is now a lot cleaner as well as being smaller, because Mercurial only stores the changes between each night's backup.
Further reading
While running a hybrid system doesn't give you all the advantages of a pure DVCS it is a major improvement over a plain CVCS. It also allows you and your team to get comfortable with the DVCS methodology before moving away from CVCS completely.
For more information on Mercurial, see: