Version control systems and Subversion

I had promised to talk about subversion in my post on digitizing and editing figures but never quite got around to it. A recent spate of requests about downloading Uintah reminded me of my promise. So here's the story.

Consider the following situation. It's January and you start writing a piece of code. After a lot of debugging and testing you finally decide that it's working. You run a lot of simulations and publish your results. In June you decide that there are several improvements in your models that need to be incorporated in your code. You work everything out and start modifying the code. To be safe you keep a copy of the original working code. The first few small changes work like a charm. An then you make what you think is a small change and find that the entire code is broken. So you start commenting out bits to find out what broke the code until you have reached (what you think is) the January version. But the code still does not work. After several days of frustration you find that you forgot to comment out two extra lines and finally get the code to work. Now you have to work forward and incorporate the new changes again and so on ....

A long time ago, software engineers decided that keeping tab of the changes in the code should be automated. The result was the Source Code Control System (SCCS). A story about my experience with SCCS is in order here. In 1994 I was given an urgent call by a customer in Kudremukh (a beautiful hill town in southern India). Our geostatistics code was not working and that was affecting their production planning. I flew down with the latest version of our code (in the form of a 1 foot diameter tape and a couple of 6 inch cassette tapes). The customer's version of the code was three years old. Also there were several extra features in the Kudremukh code that had been removed from the main version. I had to get the code working in a week. Luckily, our code was kept in a SCCS repository. I found the version of the customer's code and checked out that version from my tapes. A comparison of the file sizes in the customer's version and my SCCS version showed that a few files were different. After that it took me less than an hour to figure out the problem and fix it. Had I not had SCCS it would have taken me several days to find the problem.

By 1995, however, SCCS was almost obsolete and was being replaced by a better system called Revision Control System (RCS). RCS had some of the same problems as SCCS in that only one file could be controlled at a time and extra scripts were needed to manage a large number of files simultaneously. RCS was almost immediately supplanted by Concurrent Version System (CVS) which allowed much easier handling of large projects. CVS is widely used even today for source code control.

In 2001, an open source replacement for CVS called Subversion (SVN) started becoming popular. We moved our Uintah code from CVS to SVN around 2002. Subversion comes bundled with most Linux distributions and can also be downloaded from http://subversion.tigris.org/. A SVN repository is easy to set up and use. A good starting point is "Version control for non-programmers with Subversion" by Keith Fieldhouse.

And version control is not only for programmers. I have used it for proposals, papers, data, and many other types of documents. Try it out and you'll never go back to manually maintaining a zillion copies of your documents.