#2782

Moving To A Distributed Version Control System

I’ve been using Subversion to host my code on a Windows Home Server box for the past year or so. At about the same time distributed version control systems (DVCS) started to become the “hot new thing”. Git, Mercurial and Bazaar with their associated community hubs; GitHub, BitBucket and Launchpad are all getting a lot of traffic.

I’ve avoided moving a to distributed version control system because I’ve largely been very satisfied with Subversion for my single user, mostly connected scenario. The only place I’ve found Subversion lacking is in the completely disconnected case, which doesn’t happen to me very often. I’m also pretty conservative when it comes to version control, hot new features take second place to a reliable well documented “traditional” VCS like Subversion.

I’ve only been playing with this a few days but I’ve already noticed some benefits:

I like to check in as often as possible. I can check in even more frequently with two definitions of “done”. DVCS allows me to do this even more frequently with different doneness for local and central check-ins.

Done #1: Check in to the Central Repository. Even through it’s a one person project I still don’t like to break the CI server build off the central repository. This means I have to reach a certain level of “done” with each check-in; the tree builds, tests pass and static analysis passes.

Done #2: Local Check in. With DVCS local check-ins are “done” when I say they’re done. It’s simply a useful checkpoint I might want to role back to. For example I’ve added a new feature and it builds in the IDE but the build script needs some changes before the CI build will work.

This approach has implications for agile teams. It allows work on individual stories within an iteration to take place outside the master/main branch and only be merged with the main branch when they are complete. This prevents code from partially finished stories from becoming part of the main branch until the team and Product Owner decides that they are “done”. You can read more about that here…

A Git Workflow for Agile Teams

Wherein our hero describes a workflow for using git productively and painlessly in an Agile environment.

Thanks to Chris, Glenn and Peter, all of whom helped my understand why it was worth taking the time to look at this even though I was satisfied with Subversion for the most part.

Git vs. Mercurial vs. Bazaar vs. ???

I’m using Mercurial at the moment for a couple of reasons, not least that BitBucket’s pricing plan fits my needs best and the learning curve for Mercurial is reputedly better than that of Git. Both have equivalence in terms of the features I think I’ll use (yes they have differences but not one’s I’m interested in).

I really don’t want to get involved in the Git vs. Mercurial vs. Bazzar “debate”. There’s plenty on the web about it, and to be honest I don’t think it’s a interesting discussion for the most part. There’s room for several different players and as was pointed out to me the real “winner” (if we have to have such a thing) may not even be written yet.

However, I thought this was amusing “Git vs. Mercurial: Please Relax” if you have five minutes.