Software Configuration Management in a Client/Server Environment: A Case Study

When trying to track down a problem — either during development or while maintaining an already-released version — time and money are lost trying to locate the problem files. The reasons are many, including: Files change over time. In many distributed environment (such as local area networks, or LAN), file ownership is not enough to determine who last changed a file, and it is never enough to identify who made the second-to-last change. Without a history of those changes, time is wasted reconstructing what probably went into a past release. Developers keep copies of source files that inevitably begin to differ. When the time comes for a new release or for post-release maintenance, no one can identify which copy of the file was actually used in the product. Developers overwrite each other’s changes. Time must be spent repeating bug fixes or other modifications, once the problem is discovered. To identify a bug, a tester or programmer needs to work with a stable baseline. A piece of software under development may change hourly, which makes tracking down the root of a particular problem a lengthy, if not impossible, task. In post-release maintenance, support people must retrieve the files used to build a customer’s release, test against them, find the problem and fix it. The challenge is so great that often support passes on to customers the newest version in hopes that that version will solve the problem. This is a quick solution, and not necessarily the correct one.