Search the FAQ Archives

3 - A - B - C - D - E - F - G - H - I - J - K - L - M
N - O - P - Q - R - S - T - U - V - W - X - Y - Z
faqs.org - Internet FAQ Archives

comp.software.config-mgmt FAQ: General Questions


[ Usenet FAQs | Web FAQs | Documents | RFC Index | Property taxes ]
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 für 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:

Comment about this article, ask questions, or add new information about this topic:

CAPTCHA


[ 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