Evolving Beyond Version Control for Agile Development

Implementing CM
So the first question is: can we do CM using a VC tool? Since it is possible to do CM without any tool support at all, the obvious answer is yes, although it will be rather painful and a very manual process. Let's consider some of the features of tools along the VC to CM continuum.

Tool Features For VC and CM
We suggest the following classification of tool features:

• Basic Version Control (Library Management)
  • Storage of deltas (archival)
  • Check-out/check-in (create/read/update)
  • Labeling of configurations (unique identification)
  • (Example tools include SCCS/RCS/VSS)
• Intermediate VC (Concurrent Development)
  • Client-server architecture (not definitive)
  • File-based Branching with simple merging
  • (Example tools include CVS)
• Advanced VC (Parallel and Distributed Development)
  • Atomic transactions
  • Project-oriented Branching with Merge Tracking
  • Workspace management
  • Remote and/or Multi-site development
  • (Example tools include Subversion - except for merge tracking)
• Configuration Management
  • Task-based Development (e.g., change-tasks & change-sets)
  • Configuration-Items (e.g., components)
  • Integrated Change/Defect Tracking
  • Workflow/process enforcement o (Example tools include majority of serious commercial tools)

Some other features which may also be important include: scalability and cross-platform support, graphical user interfaces, build & release engineering, problem/issue tracking and process (workflow) support.

Architecture
The original VC tools were all client only, less of a problem in the Unix multi-user environment, for example, where people worked on a single machine most of the time. The archive or repository files in which different versions are stored (usually in a delta format), are directly manipulated by the client programs. The main problems with this are:

• Security - since all clients require read/write access to the archive files it is difficult to properly secure files and prevent malicious, or inadvertent damage.
• Reliability - what happens if your client machine dies in the middle of an update? If you were checking in a group of files only some of the check-in may have happened giving an inconsistent logical state. In addition, the archive files themselves may be corrupted.
• Performance - requiring direct access to files on a network file share usually does not perform as well as client/server.

Thus CM tools are typically client/server architecture (although there are a couple of exceptions - see comments on this article).

A related differentiator between VC tools and CM tools is the handling of labels (or their equivalent). This comes back to implementation: a VC tool is very file oriented, and operations on sets of files (whole configurations of the system) are implemented via updates to lots of individual VC archive files. Thus labelling becomes progressively slower as the number of files and versions grows. A CM tool will tend to store label information in a database, making the act of labelling a constant time operation. This may seem a small issue, but as response time goes down, developers become steadily more resistant to using the tool or doing the action, and will be tempted to find work-arounds or shortcuts (thus defeating the principles).

Considering open source tools, CVS stores labels in all the individual files that form the repository. Subversion recognised the inherent performance problems and this was one of the issues they addressed.

Agile Approaches to CM Tools
One of the approaches found in agile practices such as XP is "do the simplest thing that could possible work". The interesting thing is that some agile developers also take this approach to tool usage - keep it simple.

To this end, there are large numbers of agile teams using CVS, and fairly happily. In this instance, the agile practices of test driven development with a full set of unit tests available to developers, combine to make it relatively straightforward to check-in