Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!newsfeed.stanford.edu!canoe.uoregon.edu!elk.ncren.net!SonOfMaze.dpo.uab.edu!news-ext.gatech.edu!peerfeed.news.psi.net!filter.news.psi.net!psinr!client!not-for-mail
Mime-Version: 1.0
X-Newsreader: knews 1.0b.0
From: [email protected] (Dave Eaton)
Subject: comp.software.config-mgmt FAQ: General Questions
Newsgroups: comp.software.config-mgmt,comp.answers,news.answers
Summary: Software Configuration Management general questions.
        Part 1 of 3 related CM posts.
Keywords: FAQ, CM, SCM, Software Configuration Management
Followup-To: comp.software.config-mgmt
Reply-To: [email protected]
Expires: 23 Sep 2002 17:00:00 GMT
Approved: [email protected]
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Lines: 1238
Message-ID: <Xxtf9.2$wH3.195@client>
Date: Tue, 10 Sep 2002 21:32:39 GMT
NNTP-Posting-Host: 206.7.12.104
X-Trace: client 1031693559 206.7.12.104 (Tue, 10 Sep 2002 17:32:39 EDT)
NNTP-Posting-Date: Tue, 10 Sep 2002 17:32:39 EDT
Xref: senator-bedfellow.mit.edu comp.software.config-mgmt:27931 comp.answers:51333 news.answers:237620

Archive-name: sw-config-mgmt/faq
Last-modified: 2002/09/10
Version: 9.0
Posting-Frequency: monthly

           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:
                        [email protected] (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 [email protected] 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:
     [email protected]   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:
     [email protected]

    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:
     [email protected]

    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
  [email protected].)

  (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 [email protected] 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 '[email protected]'. 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 [email protected] 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:[email protected]

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.