Last updated: February 06, 2008

Configuration Management & Change Control

Purpose:

Large code systems typically are composed of multiple files which constitute independent compilation units, some of which may have parameters controlling how they are built.  Controlling when and how these compilable units get converted into executable code is the function of a build tool.  Unix scripts and the “make” facility are simple tools that let you build only the portion of code that needs to be built at any given time.

Multiple developers working on the same set of code can cause problems for each other unless access to the code is controlled.  Even individual developers can cause problems for themselves.  A version control or revision control system safeguards the code, data, and documents so that nobody stomps on anybody else’s changes, and allows the code to be rolled back to any previous version if necessary.  You have a couple different options for how to manage your code.  CVS is a version control system implemented on top of the capabilities provided by RCS.  Subversion (SVN) is an open-source product envisioned as a replacement for CVS.

Expectations:

You are to use your CS Department Unix account and CVS or SVN to manage and archive your project code even if you are doing development on other systems.  Updates to your code in CVS or SVN should be done frequently so that the archive is never significantly out of date with your developmental versions.  The logs created by CVS or SVN allow you to track the history of when and how the code evolved.  Another tool, StatCVS-XML which is compatible with CVS and StatSVN which is compatible with SVN, are used to be used to process the logs and create web-based displays of the repository's management data, giving a visual perspective on the code's evolution.  This is an important source of information for managing and assessing the status of your product development efforts.

The CVS or SVN tool will help you manage the introduction of changes into your code.  However, CVS or SVN alone cannot provide all the control that's needed.  There will be times during your project when it will be important to tightly control, or even prevent changes from being introduced.  These periods are often called "code freezes."  When the code is "frozen" no new capabilities are allowed to be integrated into the code base.  The only changes that may be allowed are related to correction of defects that have been discovered through testing, have been evaluated for impact and criticality, and are approved for integration into the code.  Frozen versions of code should be created and used as the basis of each release you make to your customer.  A freeze should take place several days before the release and no changes should be made just prior to the release.   If a change is required during the freeze period, it is important that you run your full regression test suite after the change is made and before the release is posted.

Tools: 

For CVS:

For SVN: