Version Control

 What is version control?

A version control system provides a repository for recording changes in source code and associated artifacts. It is a place to keep track of how software changed, when it changed, and who changed it. The most commonly used version control systems at UCAR/NCAR are currently Subversion and CVS.

Why use version control?

Joel Spolsky's "Joel Test" of 12 simple questions for rating the quality of a software project has as its first question: "Do you use source control?". There's a good reason for this question being first: source control, or version control, is generally quite simple to do, but is an absolutely indispensable tool for software development at all scales. Important benefits of version control include history, communication, and release management:

Version control keeps a history of changes. This means is is easy to move back to a working version if a bug is introduced (undo), and means it is easier to isolate the source of a bug. History is useful even in the case of a single-developer project; add more developers and this history, including the history of who made changes, makes collaboration simpler and takes away many of the pitfalls.

Version control systems allow enhanced communication among developers, since they allow for viewing where other developers have introduced changes. Also, most version control systems allow for some form of automatic notification when content is added or changed. This can provide a simple and very powerful means for communication among developers.

Release management
With tags, version numbers, etc., it is generally easy to handle software release management with version control. Properly done, it is easy to retrieve any previous released version easily. It is also generally possible to create branches so that patched versions of individual releases can be generated, without disturbing other development.

How do I start to use version control?

The simplest way to start to use a version control system is to find one already being used by your colleagues. Most groups in UCAR and NCAR already have version control infrastructure in place for either Subversion or CVS, as well as others. Contacts for some locally available version control systems are provided below.

Version Control Software Contacts


GroupContactVersion Control Software
EOLGary Granger ([])Subversion, CVS
ESSLErik Kluzek (CCSM) ([])Subversion, CVS
SERESeth McGinnis (ISSE) ([])Subversion
UOPSteve Emmerson ([])CVS


Many version control systems have assorted interfaces available, up to and including plugins which can allow for seamless integration of version control into integrated development environments (IDEs). See Documentation below for more information on how to use some specific version control systems.

Hints for good version control

  • Write descriptive check-in messages. Changes can be more easily understood if they are described clearly, especially if the "why" for a change is included. This iscritical for projects with many developers, but is also useful as persistent memory for a project with one developer.

  • Check in early. Check in often. Changes which have not been checked in can be lost easily. It is much simpler to back out a change that has been checked in than it is to recreate a change that has been lost or deleted before check-in.

  • If possible, verify that changes will compile before checking them in. Sometimes this will conflict with checking in often. In these cases, err on the side of checking in often.

Which is the best version control software?

As with most similar choices in software engineering, this is a completely loaded question, with no 'best' answer. That said, and if you are impatient: use Subversion. Subversion was developed as a successor to the currently most widely used version control system, CVS, and answers its biggest shortcomings. Subversion is also well established in the software development community, and both Subversion and CVS are widely used at UCAR/NCAR. These two are not by any means the only version control systems available, though, and individual projects and developers have both of these as options, as well as many others.

Most version control systems largely overlap in terms of the function they provide. In general, they all allow one to check out a copy of an existing project for local editing, create a new project, check in (or save) changes to be recorded by the versioning system, retrieve old versions, examine differences between versions, examine a history of change logs, etc. The differences between version control systems lie mostly in the details of how they perform their function and in breadth of extra features and interfaces. For instance, some keep their repositories in a distributed form, while others rely on a centralized repository. Some perform check-in actions atomically, while others can potentially fail in the middle of a check-in, leaving some pieces not checked in or even in limbo.

Comparisons of assorted version control systems abound on the web. Here are a couple of useful sites that provide a wide view of available systems:



    As a rule, all of the version control systems out there will do a reasonable job with the basic functions of version control. If you need specific features, then consult the above comparison sites (and others) to find what you need. Remember, though, that there is a lot of community familiarity with CVS and Subversion, which provides a strong argument for using them, especially in projects with many developers.