why is version control so hard?

I was listening to the latest stack overflow podcast where the discussion floated round to version control.  There seemed to be a general consensus that version control is hard. This seems like nonsense, but in actual fact it’s completely true.

My first experience of version control was with SourceSafe – I had met CVS briefly at uni but at the time couldn’t see the point, and without the need to understand it for an exam, there seemed little point in pursuing it further. Even having no experience of version control prior to SourceSafe, I still knew it sucked.  Why? Well the fact that I couldn’t edit a file that someone else had already checked out seemed absurd – especially as people had the tendency to leave files checked out when they went away on holiday.  Creating branches also seemed like a kludge, the result being no-one used them.  However, it was pretty easy to understand so Microsoft got something right!

After this I moved to an organisation that used ClearCase.  Oh boy this was hard.  I just didn’t get it. For about the first 2 months I had to get a friend to edit my config specs to pull in the correct files!  I can’t explain to you how much I just didn’t get it.  It was like black magic. Then one day it just clicked (akin to the day you finally get pointers). If I look at a config spec now (see below for a simple example) I just don’t understand why I didn’t get what was going on!

# First select any files that are checked out to this view
element * CHECKEDOUT

# Pull in the latest version of any files that are on the branch GREGG_BUGFIX
element * .../GREGG_BUGFIX/LATEST

# Get everything else for the latest off the mainline
element * /main/LATEST

I like the idea of the config spec a lot, and I actually think it is a pretty good system for pulling in different files from different branches.  Subversion is nowhere near as nice as this.  The problem, however, is that you need a file system (or workspace of some sorts) that is aware of how to interpret the details in the config spec to make this work, and I think this is ClearCase’s ultimate downfall; it’s just too costly to setup and maintain, you essentially need an admin working on it alone, this is ignoring the fact that it costs an fortune to buy.

Next I moved onto Subversion.  The philosophy behind Subversion is not too dissimilar to that of ClearCase, so it was a relatively easy step.  However, managing a Subversion repository is substantially more user friendly than managing ClearCase views and VOBS. Although I really hate the idea of automated merging, which everyone tended to avoid like the plague when using ClearCase, it seems impossible to escape with Subversion?

So why is ClearCase/Subversion so difficult to understand?  I’m not even sure now, as it all just seems natural, from creating a view, to writing a config spec, checking out files, branching then merging in the changes. Do we basically accept that it’s one of these things that take time to understand? The problem we have is that many people either give up or try to use each system like SourceSafe – I have seen this happen.  Furthermore, I have also worked with, and heard about many others, that just do not get concurrent version control and branches, and point blank refuse to use it.  I wish I could come up with a golden piece of information that switches on how it all works, but I can’t seem to put my finger on it.

What I tend to suggest to people is experimenting with the different features of a version control system; primarily branching and merging, as this is what tends to catch people out. Experience seems to indicate a fear of doing things wrong, resulting in lost work, is a particular issue.  However, to combat this (with Subversion), I suggest making a copy of your working folder (including the .svn directory) prior to experimenting.  Now you can perform an SVN update or merge without the fear of “losing” anything you have done (you simply copy the contents of the folder back and start again if need be). This may bad practice, I dunno, but it’s a policy that saved me a few times during a complex merge.

Moving towards the future it would appear that distributed version control systems are going to be the next big thing.  I have a little experience using Mercurial, but I kind of feel a bit like I did when I first started using ClearCase – out my depth. I do however love the idea of checking in constantly, without it being a public operation.  It also seems to me that it is a very nice model to use for having your live website under version control.  However, it’s all still pretty new to me, and I admit to being a little scared of it.  All the same, I’m following my own advice and just getting stuck into using it, even if I do make a mistake or two, as it seems like the only way to learn.