|
Archive-name: sw-config-mgmt/faq
Last-modified: 2002/09/10 Version: 9.0 Posting-Frequency: monthly See reader questions & answers on this topic! - Help others by sharing your knowledge
Configuration Management Frequently Asked Questions
Introduction
This is 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:
* Subject: comp.software.config-mgmt FAQ: General Questions (this
text)
* Subject: comp.software.config-mgmt FAQ: Configuration Management
Tools Summary
* Subject: comp.software.config-mgmt FAQ: Problem Management Tools
Summary
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:
* cm-tools = Configuration Management Tools Summary (this document)
* faq = General Questions
* prob-mgt-tools = Problem Management Tools Summary
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-2001
by Dave Eaton. It may be freely redistributed 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
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.
Please send your comments and suggestions for improvements to the FAQ
editor:
dwe@arde.com (Dave Eaton)
_________________________________________________________________
--[ 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 deja.com
(http://www.deja.com) 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:
* Traditional Configuration Management - checkin/checkout control of
sources (and sometimes binaries) and the ability to perform builds
(or compiles) of the entities. Other functions may be included as
well.
* Process Management - control of the software development
activities. For example, it might check to ensure that a change
request existed and had been approved for fixing and that the
associated design, documentation, and review activities have been
completed before allowing the code to be "checked in" again.
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:
* The CM FAQ set (these documents) at http://www.daveeaton.com/scm/
* CM Specialist Group of the British Computer Society at
http://www.bcs.org.uk/siggroup/sg57.htm
* Some research papers about CM are available at
http://wwwsel.iit.nrc.ca/projects/scm/
* A list of WWW sites for CM (including some Macintosh information)
at http://wwwsel.iit.nrc.ca/favs/
* A searchable software engineering bibliography with a subsection
devoted to CM at
http://liinwww.ira.uka.de/bibliography/SE/index.html
* R. S. Pressman & Associates, Inc. Software Process Improvement &
Software Engineering Resources information online at
http://www.rspa.com/spi/SCM.html
* A copy of the Software Engineering Institute Capability and
Maturity Model (SEI/CMM) may be found at http://www.sei.cmu.edu/
* Linux Configuration Management and Version Control at
http://linas.org/linux/cmvc.html
* Macintosh Version Control (a summary of Mac tools) by Richard
Wesley at http://www.electricfish.com/hawkfish/macvcs/
* Problem Management & Bug Tracking for Linux at
http://linas.org/linux/pm.html
* MIL-STD-498 Software Development and Documentation at
http://www-library.itsi.disa.mil/mil_std/std498.html Its purpose
is to establish uniform requirements for software development and
documentation. It merges DOD-STD-2167A and DOD-STD-7935A.
* Brad Appleton's Software Configuration Management (SCM)
definitions at http://www.enteract.com/~bradapp/acme/scm-defs.html
* CM Today - "Your Source for Daily Configuration Management News"
at http://www.cmtoday.com.
* "Evaluation and Selection of Automated Configuration Management
Tools" at
http://www.stsc.hill.af.mil/crosstalk/1995/nov/evaluati.html
* "Software Configuration Management Tools: Getting Bigger, Better,
and Bolder" at
http://www.stsc.hill.af.mil/CrossTalk/1996/jan/cmtools.html
* "The Software Configuration Management Technology Report" at
http://www.stsc.hill.af.mil/cm/index.asp
* "RAVEN Configuration & Project Management" at
http://www.configuration.org/
* TechStreet offers various engineering standards (including some
concerning SCM) for sale to their customers at
http://www.12207.com/
* Chrooted SSH CVS server HOW-TO at
http://www.idealx.org/prj/idx-chrooted-ssh-cvs/dist/chrooted-ssh-c
vs-server.html
SCM training is available from several sources. Some of these are:
* Association for Configuration and Data Management (ACDM) at
http://www.acdm.org
* Institute of Configuration Management at http://www.icmhq.com
This is not a 3 or 4 day "introduction". CMII training usually
incorporates about multiple 3-days courses for a CM certification.
There is a strong hardware focus.
* GfKM - Gesellschaft fr KonfigurationsManagement at
http://www.gfkm.de offers the CMII process of the Institute of
Configuration Management (see above) in German language in all
German speaking countries. They also offer individual workshops
and special basic CM classes.
* Integrated Support System at http://www.isscorp.com
Course is reportedl a basic 3 or 4 day intro to SCM.
* Learning Tree at
http://www.learningtree.com/us/ilt/courses/342.htm
Offers a basic SCM course that is about 4 days long.
* System Technology Institute at http://www.stitraining.com
STI offers two SCM courses, Software Configuration Management
Fundamentals and Practical Implementation of Software
Configuration Management. This company offers advanced training
courses and advanced certification for students who demonstrate
advanced knowledge of SCM in the form of a thesis paper.
* Technology Training Corporation at http://www.ttcus.com
TTC offers Effective Software Configuration Management and
Advanced Configuration Management classes. They also offer
hardware CM classes.
Additional WWW sites are listed at the ends of other segments of
this FAQ:
* Configuration Management Tools with World Wide Web sites
* Problem Management Tools with World Wide Web sites
[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.) If it appears the tool should be included,
please send the product name, preferred company address, phone,
email (if any) contact information and supported platforms to the
editor:
dwe@arde.com
so it may be included in the address portion of a future issue.
Please follow the format used in the product summaries. Error
corrections to this information are also accepted from vendors.
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".
* If you are new to news, read "news.newusers.questions" and related
FAQs before posting here. Most FAQs are posted in "news.answers"
and related "*.answers" groups and archived at rtfm.mit.edu and
elsewhere. Also, read the other segments of the FAQ for this group
and read the articles in this group for a while before posting
your own comment.
* If someone asks about a tool that has features xyz or helps to
solve problem xyz, vendors should refrain from posting "my tool
does that" responses which would clutter the newsgroup. Of course,
any private email response may be made at the vendor's or user's
discretion. As always, users are encouraged to summarize pertinent
email to the newsgroup.
* If someone asks for people's experience using a tool, then the
vendor of the tool should not offer any opinion. Please leave it
to users.
* If someone asks for a comparison of tool x with tool y, then
neither vendor x nor vendor y should offer any opinion. Please
leave it to users.
* Vendors are allowed and encouraged to comment upon and clarify
issues raised by others on the use of their tool. The discussion
should stay technical and "what the tool does" as opposed to "this
way is better than this other way". This is one of the main ways
vendors can contribute to discussions here.
* Vendors are allowed and encouraged to make brief announcements of
significant new versions or products which are shipping now. It
would be best if this announcement pointed readers to other
sources for more information (such as FTP and WWW sites or email
lists.)
* Vendors are requested not to send unsolicited mass email (spams)
concerning their products to people who post on this newsgroup.
These are usually unappreciated and tend to have a negative impact
on recipients. A short, appropriate post to the newsgroup as
described above would be preferred.
[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:
* CM is a "Good Thing".
* CM is intended to help developers.
* Integrating CM into a development environment should be
"evolutionary", and not "revolutionary". It takes time and
iterations to do it right.
* Develop a proven, bulletproof implementation of an integrated
CM/Development process, then apply it from day one on new project.
* Automation of a good CM process improves the likelyhood it will be
followed and can improve productivity and quality.
* Automation of a bad CM process can be worse than no automation.
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].) If
you have a particular comment or correction you want to be certain
the FAQ editor notices, please also copy or forward that
information to:
dwe@arde.com
so it may be considered for a future post.
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:
* desire to protect their huge investment in software and be able to
reproduce a build with the correct components or continue
development on a project even if those previously working on it
have left the company or become seriously ill
* desire to improve quality and reduce errors caused by building
products with the wrong version or some old code which did not
include a current fix
* simplification of a complicated build and/or release process
* desire to streamline processes and let developers worry about
actual development
* reduction of day-to-day labor, thus allowing an under-staffed or
over-busy team to produce more useful work
* facilitation of moving personnel from one project to another with
little or no loss of productivity since both projects follow the
same process
* elimination of instances in which software needed to investigate
customer-reported problems could not reproduced or rebuilt
* hiring of new team members (particularly leaders and/or managers)
who had good experiences with SCM in prior businesses and
advocated such improvements
* need to perform concurrent development at multiple locations,
particularly if that is already being tried and has gotten out of
hand
* improvement of the faith a Quality Assurance group can have in a
new version of a product for which they are responsible, and
highlighting of areas where a new product version should be
scrutinized during Quality Assurance
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:
* good planning and design by people experienced in good SCM
techniques
* proper and complete education of those who will be following and
using the system so that they understand not only how to, but why
they must perform certain steps and the benefit to them of doing
so
* sufficient time for the users to become familiar and comfortable
with the system
* advocacy of the new system by "champions" both in the technical
staff and management
* proper equipment and trained support staff to answer questions and
solve problems when they arise (or better still, to tend to the
continual care of the system so problems are avoided)
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
FAQ editor
email:dwe@arde.com
User Contributions:
[ Usenet FAQs | Web FAQs | Documents | RFC Index ]
Send corrections/additions to the FAQ Maintainer: dwe@arde.com
Last Update March 27 2014 @ 02:12 PM
|
comp.software.config-mgmt FAQ: General Questions
Search the FAQ Archives
N - O - P - Q - R - S - T - U - V - W - X - Y - Z
comp.software.config-mgmt FAQ: General Questions
[ Usenet FAQs | Web FAQs | Documents | RFC Index | Restaurant inspections ]
Comment about this article, ask questions, or add new information about this topic: