Distributed Version Control – Getting Started
It’s not just for academic hippies
There have been a lot of people talking up Distributed Version Control Systems (DVCS). Until recently, I’d assumed that it was the same people who have been talking up Linux for the last 15+ years. Don’t get me started on them. It seemed the principal argument used by many people was ‘everyone has their own repository’. To me, that sounded like a recipe for disaster – I’m far happier with the concept of a central, authoritative repository.
So I was surprised when Joel Spolsky came out in favour of Mercurial (or Hg), a DVCS. Joel’s a fairly level headed, mainstream kind of person – what was he doing fraternizing with the Linux-loving hippies and beatniks? After reading his Hg introduction, I realized I was in danger of becoming a convert too. When you’re done here, you may want to go over to hginit.com – you won’t find a better introduction to Hg or distributed version control in general.
What’s so good about it?
So, it turns out that DVCS is a viable alternative to regular, vanilla flavored version control. And by that I mean Subversion or CVS, the systems I’m most familiar with. There’s a few main points that convinced me to give Hg a try:
- It’s not too dissimilar to ‘normal’ source control, meaning it’s fairly simple to make the transition (add files, update, commit, revert etc work basically the same way)
- Rather than worrying about ‘everyone’ having a repository, the key thing is that you have your own local repository that’s just for you. So you get the safety net of frequent check-ins without having to worry about ‘breaking the build’.
- Branching is something a lot of people strenuously avoid with Subversion, because the tools just aren’t set up to handle it easily. Because of the way Hg tracks changes, merging branches is a simpler and more reliable process.
- Mercurial still supports the idea of a central repository, and in fact handles multiple staging servers (development, stable, release etc) fairly well.
I’ve been using Hg on a couple of projects for a while now, and I like it. The big wins for me are how simple it is to set up a new repository and how convenient it is to have a local repository for frequent check-ins.
So what’s needed to get started? Well the good news is that all the tools you need are freely available and well made. First off, you really should read Joel’s introduction. After that, the command line tools are available from here. Using the command line is a great way to learn a version control system and really understand what’s going on – and it’s surprisingly simple.
Sooner or later though, you’ll want to look at some sort of GUI though to speed the process up. @bunnyhero put me onto MacHg which I’ve been using for a week or so now it’s been excellent. There’s a good screencast that covers the basic features of MacHg and will get you up and running straight away.
You may think that not having your version control inside XCode is a pain, but in fact I think it’s a huge bonus to separate IDE and version control. I’ve never seen source control handled properly inside an IDE (I’m thinking Visual Studio, Eclipse and XCode here). Version control is about files and folders, and I don’t want the IDE thinking it know better than me how to apply version control to a project by making ‘assumptions’ to try and streamline the process.
And finally, one of the strengths of version control is that it forces you to maintain backups of your code base. And the best backup is an off site one. Setting this up is a pain, right? Actually no, as once again Joel comes to the party and makes this easy. His company Fogcreek offer remotely hosted project management, bug tracking and version control tools, including support for Hg (they call their Hg toolset Kiln).
Obviously this is service you pay for, right? Yes. Unless you are a student or small company (or in fact anyone who doesn’t need more than two active users), in which case it’s FREE. Setup is trivial, and before you know it you can have a professional grade offsite Hg server of your very own.
While you’re at it, you also get their Fogbugz tools as well, so simple bug tracking, scheduling, wiki, code review and customer support all come as part of the free package. Nice. I should point out I get nothing for recommending Fogcreek, I’m just a bit of a fanboy.
Give it a go
So there you are, if you’re looking for an easy way to get into source control, or you’re sick of merging branches in Subversion, you might give Hg a go. All the tools you need are freely available for a small scale team and the learning curve is not that steep.
One last detail – I did have a little trouble getting MacHg to talk to Kiln . The problem is that MacHg needs the URL to include your username and the repository URL, and separates them with an ‘@’ symbol. Kiln’s user names are typically your email address , so MacHg get’s a little confused when it sees something like:
Fortunately, the solution is fairly straight forward, you can ‘escape’ the ‘@’ symbol in your user name like so:
No related posts.