User login


You are here

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 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.


N. Sukumar's picture


Thanks a lot for the introduction and pointers on version control. I do use codes that are maintained under CVS and can definitely see the benefits of the same for code maintenance, apart from the ability for a large number of developers to easily work on the same code. Without CVS/subversion, this becomes a non-trivial and error-prone exercise. Hopefully, sooner than later, I will learn and adopt subversion in some of my own code development endeavors, and the links you have provided would be useful to get started.


The user interfaces for cvs and svn are identical (almost) though the internals are slightly different.  Once you have created a repository, the same basic commands apply.  For instance, instead of "cvs checkout" you have "svn checkout" to check out a copy of the code.  Similarly, "cvs add" becomes "svn add", "cvs commit" becomes "svn commit", "cvs update" becomes "svn update", and "cvs diff" becomes "svn diff".  The versioning is a bit more fine grained in svn (with every new commit leading to an update of the version).

The main benefit of svn over cvs (that I see) is that a new repository is very easy to create with svn and new trunks can be easily spawned off from a tree.   If you already know cvs you will only need to learn a few more rarely used commands to get going.

-- Biswajit 

Elizabeth M Kallman's picture

Nice history of Subversion.

Mark E. Walter's picture


 I am always looking for better ways to collaborate on proposals. I could see LaTex and SVN working well together, but what can you do with MSWord? A recent experience with GoogleDocs convinced me that it was not quite ready for what I wanted to do (figures, automatic labeling/numbering, etc). How did you collaborate with SVN? I find it hard to beat tracked changes in MSWord, but it is still best to work serially and not in parallel ...

 thanks, mark



I'm a Unix and LaTeX person myself and Subversion has served me well.  However, I've heard that you can use the MS-WIndows version of subversion (called TortoiseSVN ) for dealing with Word documents reasonably well. You could try out the instructions at Tips and Tricks on Word document management using SVN.  I wonder well that works when multiple people are commiting changes simultaneously.

-- Biswajit 

biplab's picture

SVN works well with plain text files. It can't generate binary diff. Binary diffs are not that easy to create and manage. And often the binary diff size is much higher than a normal text file diff. Some specialised tool, xDelta (, can generate binary diff.

SVN may work well with latest doc files which are xml based. But the older doc files are binary files and are not directly manageable by SVN.

You may use in-built version management system of MS Word. Read the following article-



That is handy Biswajit, thanks. I am in the same boat with you Mark and I have to work with teams who still cannot leave MS Word. I find the doc only medium bland and a non-differentiator for sales. If they were open to at least use Google Docs things would be a lot more efficient but that still leaves the medium.

I created an app with Ruby on Rails called Honeypitch to be able to have teams collaborate and embed video, slideshows, Google spreadsheets, and more so I do not have to send 4 separate documents. It was designed for in house use then we had developers make it available for others. 

The TortouseSVN tip is handy and I will share this with the team I work with who is afraid to use anything other than MS Word.



Proposal Automation and Sales Collaboration:

"Mashup Your Passion with Honeypitch"

Subscribe to Comments for "Version control systems and Subversion"

Recent comments

More comments


Subscribe to Syndicate