How We Got from Version Control to Product Management


In his CM: the Next Generation series, Joe Farah gives us a glimpse into the trends that CM experts will need to tackle and master based upon industry trends and future technology challenges.

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


About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.