Source control, revision control, version control, call it what you will, but at least use it! For those of you who don’t know what it is, it is roughly a process in software development whereby changes to source code, documents, applications etc. are tracked over time, in such a way that it is possible to reliably reconstruct any previous or current version. For a bit more of a comprehensive explanation have a look at Wikipedia’s Revision Control article. This blog is really is a cry from the heart to those people in software development not using it to start using it for code management. If you do use it and you are using a conventional centralised system, then take two minutes to read about distributed revision control - it may not be relevant to you today, but its worth knowing about.

What I am trying to get across here is that it is a very important part of the software development processes and tool sets. If for no other reason, it acts as an additional backup, and can greatly aid in the debugging process. For example, if a bug is discovered that hasn’t cropped up before in an updated feature, then by at least comparing the most common version with the previous known working version, it can help narrow down the location of that bug, or the change that may lead to the bug.

The bigger the code base and the more people involved, the more important it is to use software to manage it. These days there is a huge choice, both commercial and open-source. As with all software everybody has their favourites – in my opinion using any of them is better than none at all. Even if, for what ever reason, you can’t install one of the many commercial or open source ones, then develop a process to at least store different versions of code if sub directories/folders.

I’ve recently taken look at two open-source offerings for our own use, Subversion and Mercurial. This blog is not going to start comparing one with another, or comparing the virtues of Subversion with Perforce, CVS, Sourcesafe or similar, or Mercurial with Git etc. Subversion is a more conventional centralised version control system where all code is maintained in a central repository, and Mercurial is a distributed version control system, where changes to code are passed around on a peer to peer basis via a set of patch files. The latter approach is prevalent in software development areas such as Linux kernel development. The vast majority of developers tend to use centralised systems (at the moment), as the distributed systems are still relatively new and unknown - the working model takes a bit of getting used to if you’ve always used a centralised system.

Colrosa will probably end up using a combination of the two, depending on the type of work we are doing. Both integrate well in to the Netbeans development environment that we use. Subversion, being more mature has better support for client tools and there are plenty of quality hosting services available too e.g. Hosted Projects and Beanstalk. Mercurial is very fast, and allows easy working when disconnected from a central server, and as it works on the basis of branching all the time, it is brilliant at being able to recombine branches – something which in most conventional systems is painful.

Using a version control system should become a regular part of your daily software development life, so it is critical to get one that works the way you want to. From this point of view, you really need to trial different types of systems, and both Subversion and Mercurial are excellent examples of each flavour. It is also important to trial them in realistic scenarios, performing operations such as branching, file renaming etc. rather than the simple checkout, modify, check-in routine that they obviously all do very well.

As I have already alluded to, I was really taken with the distributed model and glad to discover it after years of using centralised systems, but it certainly doesn’t fit all ways of working.

Again, all I ask is that if you aren’t using one, try and start – you won’t regret it.

Miles