Last-modified: 2002/09/16 Version: 9.0b

OBSOLETE: Configuration Management Frequently Asked Questions

This information is now obsolete and is retained online only for archival purposes.

Introduction

This was the Software Configuration Management Frequently Asked Questions (FAQ) file for the newsgroup comp.software.config-mgmt. It has been compiled from many sources, predominantly from contributors to the newsgroup. Many thanks to all contributors.

In the newsgroups, this message should be followed by two others, each summarizing a different area of configuration management:

Like most FAQ lists, these parts are archived at rtfm.mit.edu (and various other sites which archive FAQs, such as http://www.faqs.org/). The parts are named:

and may be found in directory pub/usenet-by-group/comp.answers/sw-config-mgmt. Those new to the newsgroups should read news.announce.newusers for general information.

For those with World Wide Web access, hyperlinked HTML versions of these documents are available via: http://www.daveeaton.com/scm/
(If you type in this URL, remember that it is case sensitive.) These are updated throughout the month as changes come in. A letter is added to the version number and the date is changed with each edit to help you determine if you've already seen it.

Not Official Statements

Please use the summary below in the spirit with which it has been supplied: for information only. These statements are composites and do not represent official positions by any particular responder's company. Remember that these users may not be commenting on the current version of a product. It is recommended that you do your own research before making a tool decision for your company.

Sharing Of Information

This document, as a collection of information, is Copyright 1995-2002 by Dave Eaton. It may be freely redistributed unedited in its entirety provided that this copyright notice is not removed. It may not be sold for profit or incorporated in commercial documents without the written permission of the copyright holder. This article is provided as is without any express or implied warranty. The content is the sole responsibility of the author and contributors, and does not necessarily represent the position of their employers nor an official position or opinion of and company. Please contact the FAQ editor regarding changes.

Newsgroups line:

comp.software.config-mgmt Configuration management, tools and procedures.

Other Information

Various products mentioned in this FAQ are the trademarks of their respective companies.

All parts of this FAQ are posted to this newsgroup on or about the 22nd of each month. (This is done manually and sometimes work interferes with this posting, please excuse any delays.)

CHARTER

Comp.software.config-mgmt is intended to be a forum for discussions issues related to configuration management (CM), both the bureaucratic procedures and the tools used to implement CM strategies. CM is a corner-stone in software development, and has a very broad spectrum. For small shops developing non-critical products, perhaps all you need is RCS or SCCS and some makefiles. For large or safety-critical systems, a more sophisticated process and implementation may be required - possibly one integrated with change management and problem management.

What this is not.

If you are not sure what we mean by CM (or SCM), please see our definition in question [1.2] below. If you still think this will help you with your PC hardware or application configuration, you are mistaken. Please see question [1.10] below for some suggestions of other more appropriate newsgroups for your question -- do not post it to comp.software.config-mgmt or write to the FAQ editor about it. Thank you.

This is not a definitive list of all available tools, nor is it intended to be. It is not a recommendation or endorsement of any of the tools mentioned. As noted above, it is a composit of opinions from the comp.software.config-mgmt newsgroup. If you have a tool you would like others to know about, please join the discussion.

** What's New this Month? **

1. Minor edits
2. Replaced reference to deja with reference to Google.

While there have been other topics discussed in this newsgroup, I tried to pull together some highlights here. All comments, content and format suggestions, and submissions for future versions are welcomed.

This version is cross posted to comp.answers and news.answers and is archived at the usual public archive sites for *.answers FAQs. Those new to the newsgroups should read news.announce.newusers for general information.

Comments and suggestions for this OBSOLETE are not accepted.

--[ Table of Contents ]--

[1.0]   === GENERAL QUESTIONS ===
[1.1]   I have heard about this group (comp.software.config-mgmt) from
        cross-postings in other groups, but it's not in my news offering.
        How can I get it?
[1.2]   What is (Software) Configuration Management (CM or SCM)?
[1.3]   How does Problem Management relate to Configuration Management?
[1.4]   What Configuration Management tools are available?
[1.5]   What Problem Tracking tools are available?
[1.6]   What inexpensive (UNIX-like) CM tools are available for a DOS platform?
        (Well-established shareware or relatively inexpensive vendor tools.)
[1.7]   Where else can I look for configuration management information?
[1.8]   How can a vendor get information into the product summaries?
[1.9]   What user and vendor comments are appropriate here?
[1.10]   How do I reconfigure my PC or its applications?
[1.11]   How can I do CM in a mixed platform network?
[1.12]   Will a sophisticated CM system solve my problems?
[1.13]   How should a CM system relate to process enforcement?
[1.14]   What is the "best" CM tool to use?
[1.15]   How should I version control my Web site?
[1.16]   Are job postings permitted in this newsgroup?
[1.17]   What is the history of Revison Control and Configuration Management?
[1.18]   How can a user add information to this FAQ?
[1.19]   What are the benefits of SCM?

[2.0]   === BOOKS ABOUT CONFIGURATION MANAGEMENT ===
[2.1]   Software Configuration Management
[2.2]   Software Engineering, chapter 29, Configuration Management
[2.3]   Software Configuration Management
[2.4]   Methods and Tools for Software Configuration Management
[2.5]   Software Configuration Management
[2.6]   Configuration Management Tools: a Detailed Evaluation
[2.7]   Software Management Technology Reference Guide
[2.8]   Implementing Configuration Management: Hardware, Software and Firmware
[2.9]   Configuration Management for Software
[2.10]  Multi-Platform Code Management
[2.11]  Configuration Management Models in Commercial Environments
[2.12]  Software Shock, the danger and the opportunity
[2.13]  Configuration Management: The Changing Image
[2.14]  Applying RCS and SCCS
[2.15]  Practical Software Configuration Management:
        The Latenight Developer's Handbook
[2.16]  Practical CM:
        Best Configuration Management Practices for the 21st Century
[2.17]  A Guide to Software Configuration Management
[2.18]  Configuration Management, The missing link in Web Engineering
[2.19]  Configuration Management, the changing image
[2.20]  Principles of Configuration Management

[3.0]   === PRODUCT SPECIFIC QUESTIONS ===
[3.1]   May I post specific questions about ClearCase here?
[3.2]   Is there a tutorial someplace on RCS?
[3.3]   It seems SCCS doesn't have a $Log$ like RCS does. Am I correct?
[3.4]   Is there a tool to convert SCCS data to RCS format?
[3.5]   Why do I get Ctrl-M characters in my CVS files?

--[ Topics ]--

[1.0] === GENERAL QUESTIONS ===

[1.1] I have heard about this group (comp.software.config-mgmt) from cross-postings in other groups, but it's not in my news offering. How can I get it?

Talk to your local system administrator. All sites do not automatically create new groups as they are initiated. Also, some readers do not automatically show you all new groups as they become available at your site. In addition, most newsgroup reader software (including tools such as Web browsers which may be used for that purpose) need to be configured to point to your provider's news server. Be certain yours is configured correctly. Perhaps you have access to comp.software.config-mgmt and do not realize it.

If you still have problems, try looking into something such as the NewsGuy.com service (http://www.newsguy.com) or Google (http://groups.google.com/groups?group=comp.software.config-mgmt) which also provides Web-access to recent articles.

[1.2] What is (Software) Configuration Management (CM or SCM)?

There are a number of different interpretations. For purposes of this newsgroup, we are talking about tracking and control of software development and its activities. That is, the mangement of software development projects with respect to issues such as multiple developers working on the same code at the same time, targetting multiple platforms, supporting multiple versions, and controlling the status of code (for example beta test versus real release). Even within that scope there are different schools of thought: While process management and control are necessary for a repeatable, optimized development process, a solid configuration management foundation for that process is essential.

[1.3] How does Problem Management relate to Configuration Management?

Many organizations choose to integrate their problem management and classic configuration management tools to gain better control of their development activities and to improve quality.

Problem management may include call tracking, problem tracking, and change management. These are described more completely in part 3 of this FAQ.

[1.4] What Configuration Management tools are available?

Check the list of open source, free, public domain, and commercial vendor CM tools in part 2 of this FAQ, CM Tools Summary.

[1.5] What Problem Management tools are available?

Check the list of open source, free, public domain, and commercial vendor problem management tools in part 3 of this FAQ, PM Tools Summary.

[1.6] What inexpensive (UNIX-like) CM tools are available for a DOS platform? (Well established shareware or relatively inexpensive vendor tools.)

Check the list of free and commercial vendor CM tools in part 2 of this FAQ, CM Tools Summary.

[1.7] Where else can I look for configuration management information?

Topics related to software configuration management are discussed in other newsgroups as well. One such group is:
      comp.software-eng    Software Engineering Issues
Its FAQ will direct you to other possible groups to check, as well.

Try the CM Working Group mailing list which covers both hardware and software CM. Send email to majordomo@quality.org and in the body put:
subscribe CMWG

Some products have their own email lists to assist users. Check with your vendor. See information elsewhere in this FAQ about:

      cciug@rational.com   ClearCase International User Group mailing list

A number of sites are providing CM information via the World Wide Web. Some of these are:

SCM training is available from several sources. Some of these are:

Additional WWW sites are listed at the ends of other segments of this FAQ:

[1.8] How can a vendor get information into the product summaries?

If you know of a tool you believe should be represented in one of the CM FAQ product lists, first please make certain it actually relates to software configuration managment, the topic covered by this FAQ. (For example, Help Desk tools have their own FAQ and are not covered here.) Additions and changes to this OBSOLETE page are not accepted.

By request, the content of these FAQs is intended to be user-supplied, relatively short, and free from obvious extremes of opinion. (There are plenty of opportunities for company advertising elsewhere.) If you want to have a paragraph or two included, please have a user or customer post their views to the newsgroup (copying this editor via email would help ensure that it is seen.) Such additions will be edited, combined with other responses, and included in the product summary section of a future issue as time permits. (If your customers do not post to this newsgroup and cannot be encouraged to do so, vendors may submit two or three factual, non-marketing sentences to describe their product. These may be edited and included at the discretion of the FAQ editor as time permits.) Vendors are invited to correct any erroneous factual information noted in the FAQs.

Features described should represent existing product, not future plans. The one exception which has proven of value is to allow the FAQ to indicate platform ports in progress which will be delivered "soon". This should help customers determine candidate tools, since there is a long lead time required for a site to choose and implement a CM environment.

Users should refer to the answer to question [1.18].

[1.9] What user and vendor comments are appropriate here?

Heated discussions often have been raised in this newsgroup concerning what are appropriate comments from vendors and users. While there is no desire to eliminate meaningful contributions from either segment of the population, keeping these guidelines in mind should help hold down the "flames".

[1.10] How do I reconfigure my PC or its applications?

Although questions about PC hardware configurations, changes to ".INI" files and ".BAT" get posted to this newsgroup, they should not be. Please review available FAQs or consult articles on newsgroups such as: comp.sys.ibm.pc.*, comp.os.ms-windows.setup, comp.os.ms-windows.apps.misc, comp.os.msdos.apps, comp.os.os2.apps, or comp.os.ms-windows.nt.setup. Please review the charter of this group and our definition of CM above before posting here.

[1.11] How can I do CM in a mixed platform network?

The basic setup is that you put your source code repository on a central machine and everybody accesses that repository. Within this model, however, there are four variations, driven by two factors. One factor is if the CM tool is available on the client hosts or if you have to log into the central host to use it; the other is whether the CM respository is on a network filesystem such as NFS, Novell Netware, NetBEUI, etc.

The four variations are then:

  1. No client CM tool / No NFS.
    This is truly the poor man's solution: you must telnet or otherwise log into the central repository host, check out files, and then manually move the files back to the client host (e.g. with FTP). When you are finished, you reverse the process: move the files to the repository host, log in and check in the files.

    No one likes this solution, but there are two cases where you have no choice: first, in mixed UNIX/DOS/MAC environments, where NFS support is poor; second, in geographically distributed environments, where NFS isn't viable.

    All CM tools can be used in this way.

  2. No client CM tool / Has NFS.
    This is one step better. In this case, you still have to log into the central repository host to check out or in files, but you can access those files directly from your client host, without having to copy them back and forth.

    This solution is not exactly loved either, but is the fallback when the CM tool vendor doesn't support all your platforms. For example, you might have ClearCase installed and running on a Solaris host, exporting the managed files via NFS to a Linux host. When you have a limited number of "second class", unsupported platforms, this works fairly well.

    There is a major wrinkle with this approach due to the different line separators in text files: LF on UNIX, CR on Mac, CRLF on DOS. NFS doesn't translate these for you, and all sorts of programs (most notable diff(1)) fumble when the separator is wrong.

    All CM tools can be used in this way, as long as they are running on platforms that have some form of NFS.

  3. Has client CM tool / Has NFS.
    This is first class, transparent CM, where users check out, work on, and check in files as if the files were on their local disk. In some cases both the repository and the checked out, working files are on the shared network disk. In other cases, working files are actually on the local disk.

    This approach usually suffers from line separator problems as well.

    Freely available tools which can be used in this manner are RCS, SCCS, and CVS. Although not designed explicitly for this configuration, they are not disturbed if the repository is on a shared network disk. The problem with doing this with RCS and SCCS, however, is that the client's working files are usually "right next to" the repository files, making it hard to move the working files off the shared network disk and onto a local one. CVS is better for this.

    Commercial systems such as PVCS, MKS Source Integrity, and Microsoft's SourceSafe also rely on NFS-style access to the repository, but have better support for separating the working files from the repository.

    Other tools have populated the client workspace is with symbolic links into the repository (except for files on which the user is working).

    ClearCase has the most elaborate NFS-based solution, interposing its own filesystem (MVFS, the multi-version filesystem) between the user and the shared repository, making the versioning virtually invisible to the user.

  4. Has client CM tool/No NFS.
    For this, the CM tool must find its own way to the files in the repository, without directly sharing the repository filesystem. From the user's perspective, this approach can be as functional as using NFS, but that depends as much on the actual tool as anything else.

    CVS has a mode where it can access its repository on a central host in a manner similar to using rsh(1). The commercial system Perforce accesses its repository using its own protocol directly over a TCP/IP connection.

    Because this approach dosn't use NFS, it isn't limited to environments where NFS is supported. Both CVS and Perforce, for example, can be used across the Internet.

It should be noted that few tools are available on all platforms. You'll probably need to balance the features you want with the platforms you want supported.

[1.12] Will a sophisticated CM system solve my problems?

Discussed in many forms on this newsgroup, the simple answer is no, there is no silver bullet tool which can solve all configuration management problems by itself. Any good CM tool which provides version control is a great benefit over manually keeping copies of files in alternate directories. Including build management can provide tremendous increases in productivity. Some organizations will choose to use a tool which can provide some degree of process management. The level of sophistication required will depend upon the complexity of the software being developed and the size and dynamics of the organization doing the development. Budget may dictate what tools can be considered. As always, local CM requirements should be determined before a CM tool investigation is undertaken. (See also the answer to [1.19] What are the benefits of SCM?)

[1.13] How should a CM system relate to process enforcement?

This is a very controversial topic and many good discussions have been held in this newsgroup. Some frequently voiced ideas include: Chances for success may be improved if you first establish a process on which both the CM and development staff can agree. Consider the capabilities of the tool you will use and automate the process in a non-intrusive manner as much as possible. Process is very site specific.

[1.14] What is the "best" CM tool to use?

This is a loaded question without an answer. The real answer to this question is ... it depends!! "Best" is relative to the environment, culture, and goals of the organization you are working in. One site's best may be ClearCase or TRUEchange, another PVCS or CM Synergy, all for very good reasons. Some sites select multiple tools to meet different project needs. Each was a "best" for that situation. Your source code's future depends on how well you manage its past. Development teams need to track a project's entire history and rebuild past versions quickly and accurately-with 100% assurance of reliability and integrity-every time. Your tool selection deserves a lot of thought. It would be best to check the product literature and the other parts of this FAQ for possible solutions, then do your own evaluation.

[1.15] How should I version control my Web site?

This is a special case of SCM and may be a bit outside the traditional scope of this newsgroup. Many posters have indicated they are using their CM tool of choice to manage versions of their Web sites. Tools frequently mentioned include ClearCase, RCS, CVS, MKS, and Aegis. Refer to Part 2 of this FAQ for more information about these and other tools.

There are now some products available which address Web site issues specifically. These include products such as a Web-based management system, Intra.doc!, from IntraNet Solutions, Inc. More comprehensive answers may be found on one of the comp.infosystems.www.* newsgroups.

[1.16] Are job postings permitted in this newsgroup?

The consensus of the readers of this newsgroup is to permit short, tasteful, "jobs offered" postings which are identified as such in the subject line and which include the location of the job. A preferred subject format would be: "Job: <Location>: <Type of job>" Offers from the hiring organization would be preferred. Headhunter firms are requested to group offers into a single or small number of posts and limit the frequency with which they post. It is preferred that "jobs wanted" postings be avoided in this newsgroup.

In addition, job posters and seekers may want to refer to CM Today's Configuration Management Job Listings at http://www.cmtoday.com/cmjobs/.

[1.17] What is the history of Revison Control and Configuration Management?

This subject would take more room than is possible in the FAQ. An abbreviated, though still rather lengthy, summary of recollections from many contributors on the newsgroup is provided here for reference.

As soon as "software" began being created, there was a need to change it. The first "configuration management" was done manually. (Have you ever saved a patch-panel board for use and comparison later?)

As binary computers and their software grew, tools began to be created to help manage the software and the changes to it. On the mainframes, revision control systems were used early on as update systems which typically combined manual editing plus revision control plus some CM. Another branch was the hardware CM systems, basically fancy bill of materials systems. A third branch of CM were manual and semi-automated systems based on mil-specs. A fourth branch of CM consists of the UNIX tool set utilities and their clones.

In early cases, the source or binary of the programs were typed on typerwriter-style machines and stored on physical media such as punched paper tape and punched cards (yes, this was pre-video and pre-magnetic media days - no file systems). Frequently there were methods of punching leader or lead cards with patterns which could be recognized and read by humans to identify the program and its revision number or date by looking at the tape or card deck. Complete copies of the paper tape or card decks were kept to enable developers to return and maintain earlier versions. "Golden releases" consisted of punching mylar tape rather than paper tape. (Of course the mylar tape didn't get out of order if dropped and wasn't erased by being placed near a magnet.)

As technology advanced, the physical media migrated to magnetic media. Reels of tape were archived. The advent of smaller media with larger capacity gave rise to the "floppy in the drawer" method of version control, but version control was still manual in many development shops.

The early software configuration management process was manual, also. The "checkout" process often consisted of writing the developer's name on a paper or blackboard next to the module name. "Checkin" was accomplished by erasing the name. A more "modern" manual process used items such as colored map pins in a cork board. Each developer was assigned a pin color and their pin was placed in successive boxes beside each module's name to migrate who had rights to edit, load, and test a particular software module through its development cycle.

(Aren't we glad we have tools that can do these tasks for us today?)

In the late 60's Early 70's, Professor Leon Presser at University of California Santa Barbara did a thesis on change and configuration control. This concept was a response to a contract he was working on with a defense contractor who made aircraft engines for the Navy. As you can guess, the AirForce also wanted to purchase that "exact" same engine, plus or minus about 14 million modifications.

This requirement eventually grew into a commercially available product in 1975 called Change and Configuration Control (CCC) which was sold by the SoftTool corporation.

The mainframe update systems, of which IBM's IEB_UPDATE and CDC's Update were the most important, accepted as input update decks (all of these systems were card based) which were basically difference sets, i.e., edit decks that said to insert code, delete code, and replace code. (Line editors date back a ways but it wasn't until the 1970's that they were integrated into the CM cycle.) A key distinction between these systems and the SCCS/RCS style systems is that the update sets always referenced insert and delete points in terms of record identifiers (which did not change from version to version) rather than line numbers as in file differencing systems.

Similar change code schemes were used for other systems in the 1970's to regenerate paper tape sources based upon the line or record number where the change was required. The new paper tape would then be read into the assembler or compiler to create the binary and saved as the next "version" in the cycle.

By 1970, CDC update was an advanced product. IBM UPDATE was much more primitive. Columns 73-80 were used for holding sequence numbers; you could only insert between sequence numbers. It appears to have started as a deck patch system dating back before the 7090; we are talking early 1960's or even late 1950's here. The later versions had a hierarchy of control; a control deck could specify which updates were to be applied to which decks. In turn control decks could select other control decks.

IBM's system was fairly clearly derived from patching (e.g., the UNIX patch program) which was a common thing to do in early years, both to source code and (perversely) to object code.

The most sophisticated of these early systems was CDC's update which combined revision control, change sets, preprocessor directives, and build management into one package, albeit with a heavy FORTRAN slant. (The system continued on for quite some time and eventually incorporated file differencing for delta generation.)

There have been quite a variety of build managers. The venerable "make" dates back to the early 1970's. Concurrent with "make" were a number of quasi-expert build managers that were more or less tailored to specific operating systems. These systems tended to rely on knowledge of system conventions rather than description files and were much more convenient that "make". Thus in IBM's VM/CMS and in TOPS-20 one could simply issue a link command (or equivalent) and the linker could figure out which files had to be compiled and linked. The general weak point of these systems were their OS and environment dependence. A specific weak point is that they preceded the spread of "include directives" which make the build management problem more complex.

One of the functions of CM is version archiving. Such systems also have a long history, both in the mainframe world and in the minicomputer world. The mainframe products, e.g., panvalet, tended to be more sophisticated in the early years but by and large did not keep up with the times.

The UNIX branch is the source of most of the current commercial CM tools, most of which got started in the 1980's. A notable exception is CCC which started out as a mainframe CM product. The predecessor to TrueChange started out as a cross-platform minicomputer CM product.

The free UNIX line of tools began in the mid 1970's and includes SCCS [Roc75], RCS [Tic82], CVS. SCCS and RCS are file versioning systems; as such they are utilities in a CM system. At a minimum a CM system has to manage collections of files. CVS was later extended to include more of the functions required of a CM system, though not all.

Basically SCCS interleaves directives (delta identifiers and insert and delete directives) in with the code. There are no absolute identifiers as such but they are deducible. CDC update straightforwardly identified a record by its originating cset (the term goes back to them) and the offset within cset (i.e., foo.100 was the 100'th record inserted by foo).

SCCS directives have to be nested within the file, i.e., a delete segment cannot span inserts by different deltas but instead has to be broken up into different delete segments.

The main point is that file differencing itself is line number oriented which is a major limitation on using diff/patch. However a VC utility which uses a file differencing utility can translate the line numbers into absolute identifiers or their equivalent.

You can do delta selection in SCCS, but the procedure can be incredibly cumbersome and error-prone.

RCS is a good revisioning engine. It has limitations when trying to use it for a change based system. When code is created on a branch then merged to the trunk, the new source is replicated on the trunk delta, instead of being reused, like ADC, SCCS.

ClearCase's parent product was the early 1980's tool DSEE (Domain Software Engineering Environment) from Apollo Computer. Unlike many other tools of its day, DSEE used an interspersed delta file to hold all versions in a single file. Rather than compute and apply difference directives one after another to determine a particular version, it made a single pass through the file and delivered the correct lines to the requesting process. By the mid 1980's DSEE had build management capabilities that included automatic dispatching of component builds to remote machines on the network so that a complete software subsystem could be created in parallel from a single user command without modification to the build directives (known as a model).

One of the things that a CM system has to handle is the specification of a file set, i.e., a collection of files, each with its own version. An early example of a system for doing this was DEC's CMS which grouped versions of files into classes (CMS was basically an upgrade of SCCS for VMS with some added bells and whistles; MMS was a "make" clone.)

One of the complications in the UNIX branch was the use of directory trees. (It may come as a shock to some readers, but there are other ways to organize file systems.) Some issues are: (a) the versioning of directory tree location of files and (b) handling the existence within the file system of multiple versions of a file, e.g., sandbox areas and system build areas. The ClearCase solution from Atria/Rational was to intercept references to files within the OS file management system. This is an elegant solution but is not without problems.

The microcomputer revolution has added a twist. Many language packages are offered as development environments with an elaborate GUI front-end. Most of them include a crude CM system. (CM products have tended to be rather crude in the non-UNIX PC world at the conceptual level.) One of the notable occurences in the history of software development technology is the idea of the development environment. Sophisticated development environments are regularly created and just as regularly they become dead ends. Unfortunately, it has been a regular feature of these development environments that CM is an add-on afterthought.

Additional information may be found in the background/history section of Ron Berlack's "Software Configuration Management" book. He reviews the whys and wherefores from a program management view point which provides an understanding for the justifications for using CM principles and practices.

As a side point, one of the things that messes up version control systems is hard-wiring assumptions about naming conventions. Naming conventions are critically important in CM systems. To do things right, however, the naming policy must be configurable and must not be hard-wired into the tools. ADC decoupled conventions from the base engine. Conventions were used in the model layer, then passed onto ADC. A good example of what not to do is the version numbering in SCCS. Arguably the A: etc. in DOS is another good example of what not to do.

Marc Rochkind for SCCS, Walter Tichy for RCS, Richard Harter for ADC/TrueChange and David LeBlang for DSEE and ClearCase are but a few of the numerous people who have contributed to the advancement of CM and the CM technology over the years.

References:

[Roc75]
Marc J. Rochkind. The Source Code Control System. IEEE Trransactions on Software Engineering, SE-1(4): 364-370, December 1975
[Tic82]
Walter F. Tichy. Design, Implementation, and Evaluation of a Revision Control System. Proceedings of the 6th International Conference on Software Engineering, IEEE, September 1982

[1.18] How can a user add information to this FAQ?

This did not used to be a question anyone asked, since USENET users knew how to post to a newsgroup. However, it is arising more now that the Web has become so popular (and now that there are Internet users who do not realize that the Internet offers services besides just the Web, including USENET newsgroups.) This FAQ is an edited composit of material which has been posted by participants to its newsgroup. If you use a product which does relate to the topics covered by this FAQ (that is, software configuration management) please consider participating in the newsgroup comp.software.config-mgmt. (If you do not know what this means or how to do it, please refer to the answer for question [1.1].)

Vendors should refer to the answer to question [1.8].

[1.19] What are the benefits of SCM?

This question arises in several forms. Sometimes it is "what are the benefits", but often it is "how can I convince management to use SCM" or "what are/how can I measure the cost savings of implementing SCM". In many cases, it is an indicator of a company looking for a "silver bullet". (See the answer to [1.12] "Will a sophisticated CM system solve my problems?")

First the "bad news": designing and implementing software configuration management will cost in the short-term, it will not be a way to realize short-term savings. These costs will be incurred for design time, tools license fees, equipment costs, user training, and risks of misuse due to unfamiliarity with a new tool or platform or process.

However, the "good news" is that in the long run, that is, over the complete life of a software product, implementing a good SCM process and system which is used correctly by a properly trained development staff will save money by improving quality, reducing problems, and making maintenance and rebuilds of various product vintages more reliable.

Software development is a complex process. Companies enter into SCM practices because they want to be able to control and guide that process as best they can. How much, or how measurable, the cost savings may be will depend upon how well the company has been tracking all actual expenses of development, including debugging, redesign, corrections, etc. over the entire life of the product, not just to expenses to the first release. If they have no such metrics tracking, they are unlikely to see a savings they can recognize (and may even view the implementation of SCM as costing more).

Some of the specific reasons for implementing SCM which have been mentioned in this newsgroup over the years include:

Regardless of the reason, it is important to recognize that deciding to design a good SCM process and implement such a system is a long-term commitment. The benefits will not be realized overnight. Sufficient time (sometimes over the course of several product cycles) is required before the real benefits can begin to be realized. One error some companies make is to try SCM for a portion of a project, often never really training the developers to use it properly or not allowing them the time to become familiar and comfortable with it, not obtaining adequate hardware to support the new process, or not configuring their systems properly to support the new demands put on them. Then the company abandons the SCM system because of user complaints or, more likely, slippage of the schedule of that first project (even if the initial schedule was underestimated).

The essential elements of a successful implementation of SCM include:

A side benefit of implementing a good SCM process is that it will help enable a company to be assessed at a higher SEI Level and/or obtain ISO 9000 certification. (Note that these are side benefits, SCM should be approached from the standpoint that it can help you produce better, more reliable products faster, rather than for the purpose of attaining an award or certification.)

[2.0] === BOOKS ABOUT CONFIGURATION MANAGEMENT ===

(Hal Render maintains a bibliography of books and articles on SCM, version control, and related subjects. A searchable copy of the is on the WWW at http://liinwww.ira.uka.de/bibliography/SE/scm.html. You can ftp the formatted copy and BibTeX source from "mozart.uccs.edu" in the directory "/pub/SCM" or request a copy from him at render@massive.uccs.edu.)

(You can also check any good technical bookstore near you. One such store with a Web site is: San Diego Technical Books, Inc. and look for topics such as "Software Configuration Mgmt".)

[2.1] Software Configuration Management

by Wayne A. Babich; Addison-Wesley, Reading, Massachusetts, 1986; ISBN 0-201010161-0
(The 'bible' on configuration management? Good, easy reading, can be read in a couple of hours at most. Clearly illustrates the problems and solutions to double maintenance, shared data, and simultaneous update. Nice examples, lots of topics.)

[2.2] Software Engineering, chapter 29, Configuration Management

by Ian Sommerville;
(a nice introduction to the topic)

[2.3] Software Configuration Management

by H. Ronald Berlack; John Wiley and Sons, Inc., New York, New York, USA, 1992; ISBN 0-471-53049-2
A very useful guide to understanding and implementing CM. A classic but complete reference which includes forms of SCM used in non-automated days.

[2.4] Methods and Tools for Software Configuration Management

by David Whitgift; John Wiley & Sons Ltd., West Sussex, England, 1991; ISBN 0-471-92940-9

[2.5] Software Configuration Management

by Edward H. Bersoff, Vilas D. Henderson and Stanley G. Siegel; Prentice-Hall, Inc., Englewood Cliffs, New Jersey, 1980; ISBN 0-13-821769-6
(a classic, but reportedly out of print)

[2.6] Ovum evaluates: configuration management tools

by P. Ingram, C. Burrows and I. Wesley; by William Rigg, Clive Burrows, and Pat Ingram; (c) 1995; Ovum Ltd., 1 Mortimer Street, London W1N 7RH, England (Tel: +44 71 255 2670, Fax: +44 71 255 1995; ISBN 1-89897-210-9)
(Ovum writes evaluation reports and charges a great deal of money for them (US $1345). Their argument is that they do all the legwork for you of evaluating a range of offerings; all you have to do is pay them the money, read the results, and buy the system/tool that is best for you. All well and good - if you agree with their evaluation methods and accept that their results will hold in your environment. See http://www.ovum.com)

[2.7] Software Management Technology Reference Guide

Contact Software Management News at 73670.2227@compuserve.com to obtain copy. It list most of the current CM tools.

[2.8] Implementing Configuration Management: Hardware, Software and Firmware

by Fletcher J. Buckley; IEEE Press, 1992; ISBN 0-7803-0435-7
(discusses how CM principles can be applied to all areas of computer engineering, and not just software engineering)

[2.9] Configuration Management for Software

by Stephen B. Compton and Guy R. Conner;Van Nostrand Reinhold; ISBN 0-442-01746-4
(Well thought out and easy reading. Good discussion of standards such as ISO900 and DOD2167A along with work sheets for managing the change. Lacking an automation approach. There is little discussion given regarding the adaptation of a process change. The glossary is very helpful and there is a good bibliography.)

[2.10] Multi-Platform Code Management

by Kevin Jameson; O'Reilly & Associates; 354 pages, (includes two diskettes); ISBN 1-56592-059-7
(Intended for programming teams struggling with build and maintenance problems. Accompanying software is available for fifteen platforms, including MS-DOS and various UNIX systems. It shows you how to structure a large project and keep your files and builds under control over many releases and platforms. Uses RCS 5.5 for the version control portion. This book is no longer offered by O'Reilly, though some stores may still carry a copy. O'Reilly is referring people to the Applying SCCS and RCS book instead".)

[2.11] Configuration Management Models in Commercial Environments

by Peter Feiler; Tech Report CMU/SEI-91-TR-7, ESD-91-TR-7, March 91.
(This is not a book, but is said to be an excellent overview of CM models with discussion of the Long transaction, Change Set, Composition, and Checkout/in models, if you can find a copy. Online versions were available in postscript and pdf format at: http://www.sei.cmu.edu/activities/legacy/scm/abstracts/abscm_models_TR07_91.html)

[2.12] Software Shock, the danger and the opportunity

by Roger S. Pressman and S Russell Herron, published by Dorset House Publishing, N.Y., NY ISBN: 0-932633-20-X
(This book covers CM as a subtopic and has many examples of risks in software development. Most lessons are presented from one of the authors experiences. There is good historical perspective regarding the evolution of software design, structure of software development organizations, implications and costs associated with software development, discussion of development process and methods. It is the process that links the book to CM. It is very quick and easy reading. The book is robust with references, quotes, and citations. The authors also have a good sense of humor.)

[2.13] Configuration Management: The Changing Image

by Marion Kelly, published in the UK by McGraw-Hill Book Company Europe; ISBN 0-07-707977-9
(To quote the back cover, 'This book gives a thorough account of the state of software configuration management today'. A reader recommends to it anyone wanting some real up to date, practical advise. Another reader says 'good war stories are sprinkled throughout the book ... keeps eye on the goal and relates all CM activities to achieving that goal.')

[2.14] Applying RCS and SCCS

by Bolinger and Bronson, published by O'Reilly; ISBN 1565921178
(This book compares and contrasts RCS and SCCS and includes a large section on tccs. Tccs is their homegrown control and configuration management system, based on RCS but extends it quite a lot. Well worth reading.)

[2.15] Practical Software Configuration Management: The Latenight Developer's Handbook

by Tim Mikkelsen and Suzanne Pherigo, published June, 1997 by Prentice Hall Professional Technical Reference, (c) 1997 336 pp., Paper Bound w/CD-ROM, ISBN 0-13-240854-6
(This introductory book on configuration management includes chapters covering SCM concepts, release and maintenance operations, then goes beyond the basics to discuss change management and related topics. It discusses several freely available packages, such as RCS and CVS, as well as some commercial offerings, focusing on the PC platform and discussing free and inexpensive tools and technologies, rather systems developed for large teams. A CD is included.)

[2.16] Practical CM: Best Configuration Management Practices for the 21st Century

published by Raven Publishing Company with a new edition by Butterworth-Heinemann coming out in March, 2000; ISBN 0966124847; hard cover/CDROM
One reader reports this is the best selling book on CM this year.

[2.17] A Guide to Software Configuration Management

by Alexis Leon, published by Artech House, Inc. (Norwood, MA); April, 2000; ISBN: 1580530729; Hardcover; 384 pp
The book has a companion Web site at http://www.lnl.net/books/scm/

[2.18] Configuration Management, The missing link in Web Engineering

by Susan Dart, published in late 2000; ISBN 1580530982
The book gives good reasons for performing CM as well as examples of answers to questions of the form "you might have a CM problem if...".

[2.19] Configuration Management, the changing image

by Marion Kelly, (may be available only in Europe); ISBN 0077079779
A good job of covering the basics of SCM and has good war stories regarding implementation.

[2.20] Principles of Configuration Management

by M. A. Daniels, published in 1985; ISBN 0-934-321-08-6
Mike stays with the basic principles of CM, thus making it a timeless reference. It is also short and a quick read (and re-read.) It was still available from barnesandnoble.com at last check.

[3.0] === PRODUCT SPECIFIC QUESTIONS ===

[3.1] May I post specific questions about ClearCase here?

Yes, you may post them here and are quite likely to get an answer. However, if the question is particularly detailed, you may have more luck with the ClearCase International User Group mailing list.

To join that list, send email to 'cciug-request@rational.com'. In the body of the message place the line:

      subscribe cciug [your-email-address]
After your request has been approved and processed, you may email to cciug@rational.com and it'll be read by Rational and all those customers who are on this mailing list.

[3.2] Is there a tutorial someplace on RCS?

Try executing 'man rcsintro'. It comes with rcs. Also try to get Walter Tichy's paper "RCS - A System for Version Control" which is part of the RCS distribution.

[3.3] It seems SCCS doesn't have a $Log$ like RCS does. Am I correct ?

Users reported that there is NO keyword like $Log$ available on SCCS. They apparently implemented another way to log changes from files called 'delta table' (=some kind of database). Check out commands (on Sun4-os4)
     sccs prt              [filename] ( = show log )
     sccs cdc  -r[version] [filename] ( = add command for logging)
Also check out "sccs prs".

[3.4] Is there a tool to convert SCCS data to RCS format?

There is a GNU csh script named sccs2rcs which does this. Check the usual ftp sites. It is included in the CVS package.

[3.5] Why do I get Ctrl-M characters in my CVS files?

This seems to happen when a user checks out files from a UNIX Server while using an MS Windows/NT client. On Windows and Windows/NT lines are terminated with "\r\n", whereas on UNIX they are terminated with "\n". On check-in, text files are converted back to a platform neutral format (which happens to be newline ("\n") terminated). "make" programs that run under Windows/NT should be able to handle the standard Windows text format in makefiles. If you are moving the makefiles that you checked out under Windows/NT to a UNIX system and trying to use them there, it is likely to cause confusion. There are tools which can help you swap the line endings as needed. Alternatively, if you check out your source tree under Windows/NT, you should only use NT-based tools in that working directory. Then, if you need to do work under UNIX, check out another copy of your source tree on a UNIX system.

--[ Contributors ]--

The answers in this FAQ are often composites from many responders and I felt it would not be practical to acknowledge each one here. In addition, many companies do not want their name associated with specific statements. If you disagree with this position, drop me a message and I'll consider a change.

End of comp.software.config-mgmt FAQ Part 1

This document does not represent an official position or opinion of any company. 

--
 Dave Eaton
 Former FAQ editor
 OBSOLETE! (Retained online for archive purposes only.)