Version Control (VC) has been around long before software. But it wasn't until the late 1960s and early 1970s that it emerged as a common software function. Today, version control is still necessary, but is a much smaller piece of the Configuration Management (CM) and Product Management (PM) pictures. While Version Control is a relatively simple application, Configuration Management is anything but. No wonder it is embraced with such reluctance. But this doesn't have to be the case. The key to adopting a successful CM program is to select tools which help you to automate the complexity without taking short cuts that will lead to problems down the road.
Version control
Unix, with its SCCS capability, practically made version control a household name - at least for Unix software developers. On the VAX, it was CMS. Then came RCS and CVS. Some of these tried to be VC tools - and did very well because they addressed the VC problem properly. They also tried to do more - but not quite as well. Why? Primarily because VC typically deals with a single object at a time, while CM deals with an entire product or set of products. At it's core, version control is about saving multiple revisions of a file so that any revision can be retrieved at a future date. The version control function includes:
- Recreating an old version of a file
- Allowing creation of multiple versions and parallel versions
- Identifying differences between different versions of a file
- Merging files versions which have diverged from each other
Files are generally bits and bytes. However, when a "file" is a directory, it has a more structured content, at least as far as the version control and CM functions are concerned. A directory contains a set of files and possibly other directories. In fact, it is the contents of the directory that defines it, for the most part. And just as files can change as they are edited, so too do directories change as their contents change. The change could be subtle - one of the member files was edited. Or it could be more visible - a new file was added or an existing one renamed or removed. Just as files need version control, so too do directories. So the version control function might also include:
- Defining the contents of a directory as a specific version of the directory
- Allowing parallel evolution of the directory, such as for a supported product vs the next release of the product
- Identifying differences between different versions of a directory
- Providing a means of modifying the directory contents.
The "directory" object may be a file system object, or a logical version control object, whose definition is stored in a file or a repository. The "control" portion of Version Control often is extended to have the meaning of Change Control. Change Control defines:
- who may check out a file
- under what conditions
- when and how to branch
- when and how to merge
- how to add a comment for a new revision of a file
Change control, at the version control level, deals with controlling who may make changes to a file, and how it's version tree may evolve. A version control tool may do a good job at Change Control for a given file, but the problem is that there is a bigger picture that needs to be tied together. And data is generally stored at the file level making it harder to evaluate the bigger picture. Still, add some basic reporting tools, such as listing versions of a file, listing directory revisions recursively, etc. and you have a fairly full set of Version Control functionality. Give me a branch identifier and a revision identifier within each branch, and I'm happy. I can identify any version.
Configuration Management
A valid CM system must deal with the four basics: Identification, Management/Control, Status Accounting, and Audit. Many use this as the definition of CM, or at least the cornerstone. Version Control is an important part of configuration management. In fact, first generation "CM systems" were just version control systems with a bunch of scripting around them. I remember doing the scripting on a project in the mid '70s and again in the early '80s - as
About the author
Joe Farah is the President and CEO of Neuma Technology and is a regular contributor to the CM Journal. Prior to co-founding Neuma in 1990 and directing the development of CM+, Joe was Director of Software Architecture and Technology at Mitel, and in the 1970s a Development Manager at Nortel (Bell-Northern Research) where he developed the Program Library System (PLS) still heavily in use by Nortel's largest projects. A software developer since the late 1960s, Joe holds a B.A.Sc. degree in Engineering Science from the University of Toronto. You can contact Joe at farah@neuma.com
