NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/software/3424

Text File | 1992-09-11 | 35.8 KB | 948 lines

Newsgroups: comp.software-eng
Path: sparky!uunet!europa.asd.contel.com!darwin.sura.net!spool.mu.edu!umn.edu!csus.edu!netcom.com!dbander
From: [e-mail] (David B. Andersen)
Subject: Summary: SCCS vs RCS
Message-ID: <![e-mail]>
Date: Fri, 11 Sep 92 18:26:16 GMT
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Sender: David B. Andersen
Distribution: comp.software-eng
Lines: 936



A week or so ago, I posted a question asking about the
relative merits of SCCS vs RCS.  What follows is a summary
of your responses.

Many thanks to all for your valuable information.

---------------------------------------------------------------------
From: [e-mail]

The biggest win with RCS is that you can run CVS on top of it.

I have used CVS for a project that is some 50 000 lines of code with
no big problems. I know of a company that uses it in a much bigger
project. They are about 6 persons that often edit the same file
simultaneously. They are also pleased with it.

CVS is availble via anonymous ftp from prep.ai.mit.edu in
pub/gnu/cvs-1.3.tar.Z. It is also mirrored in various places, so you
might be able to find an ftp site closer to you.

These are the three strongest advantages of CVS over RCS and SCCS, in
my experience:

Collection of files
-------------------

One of the strong points about CVS is that it does not only lets you
retrieve old versions of specific files. You can collect some files
(or directories of files) into ``modules'' and a lot of the CVS
commands can operate on an entire module at once. The RCS history
files of all modules are kept at a central place in the file system
hierarchy. When someone wants to work an a certain module he just
types "cvs checkout bugtrack" which causes the directory ``bugtrack''
to be created and populated with the files that make up the bugtrack
project.

With "cvs tag bugtrack-1.0" you can give the symbolic tag
"bugtrack-1.0" to all the versions of the file in the bugtrack module.
Later on, you can do "cvs checkout -r bugtrack-1.0 bugtrack" to
retrieve the files that make up the 1.0 release of bugtrack. You can
even do things like "cvs diff -c -r bugtrack-1.0 -r bugtrack-1.5" to
get a context diff of all files that have changed between release 1.0
and release 1.5!

No locking
----------

If you work in a group of programmer you have probably often wanted to
edit the function foo() in bar.c, but Joe had locked bar.c because he
is editing gazonk().

CVS does not lock files. Instead, both you and Joe can edit bar.c. The
first one to check in it won't realise that the other have been
editing it. (So if you are quicker than Joe you wont have any trouble
at all). Poor Joe just have to do "cvs update bar.c" to merge in your
changes in his copy of the file. As long as you changeing different
sections of the file the merge is totaly automatic. If you change the
same lines you will have to resolve the conflicts manually.

Friendlier user interface
-------------------------

If you don't remember the syntax of "cvs diff" you just type "cvs -H
diff" and you will get a short description of all the flags. Just "cvs
-H" lists all the sub-commands. I find the commands less cryptic than
the RCS equivalents. Compare "cvs checkout modulename" (which can be
abbreviated to "cvs co modulename") with "co -l RCS/*,v" (or whatever
it is you are supposed to say - it was a year since I used RCS
seriously).

I enclose an introduction to CVS written by [e-mail]
below.
---
Per Cederqvist, Lysator Academic Computer Society., Univ. of Linkoping, Sweden
Email: [e-mail]
Phone: [phone]         "CVS - Check It Out!"
---

INTRODUCTION TO USING CVS

    CVS is a system that lets groups of people work simultaneously on
    groups of files (for instance program sources).

    It works by holding a central 'repository' of the most recent version
    of the files.  You may at any time create a personal copy of these
    files; if at a later date newer versions of the files are put in the
    repository, you can 'update' your copy.

    You may edit your copy of the files freely. If new versions of the
    files have been put in the repository in the meantime, doing an update
    merges the changes in the central copy into your copy.
    (It can be that when you do an update, the changes in the
    central copy clash with changes you have made in your own
    copy. In this case cvs warns you, and you have to resolve the
    clash in your copy.)

    When you are satisfied with the changes you have made in your copy of
    the files, you can 'commit' them into the central repository.
    (When you do a commit, if you haven't updated to the most
    recent version of the files, cvs tells you this; then you have
    to first update, resolve any possible clashes, and then redo
    the commit.)

USING CVS

    Suppose that a number of repositories have been stored in
    /usr/src/cvs. Whenever you use cvs, the environment variable
    CVSROOT must be set to this (for some reason):

    CVSROOT=/usr/src/cvs
    export CVSROOT

TO CREATE A PERSONAL COPY OF A REPOSITORY

    Suppose you want a copy of the files in repository 'views' to be
    created in your directory src. Go to the place where you want your
    copy of the directory, and do a 'checkout' of the directory you
    want:

    cd $HOME/src
    cvs checkout views

    This creates a directory called (in this case) 'views' in the src
    directory, containing a copy of the files, which you may now work
    on to your heart's content.

TO UPDATE YOUR COPY

    Use the command 'cvs update'.

    This will update your copy with any changes from the central
    repository, telling you which files have been updated (their names
    are displayed with a U before them), and which have been modified
    by you and not yet committed (preceded by an M). You will be
    warned of any files that contain clashes, the clashes will be
    marked in the file surrounded by lines of the form <<<< and >>>>.

TO COMMIT YOUR CHANGES

    Use the command 'cvs commit'.

    You will be put in an editor to make a message that describes the
    changes that you have made (for future reference). Your changes
    will then be added to the central copy.

ADDING AND REMOVING FILES

    It can be that the changes you want to make involve a completely
    new file, or removing an existing one. The commands to use here
    are:

    cvs add <filename>
    cvs remove <filename>

    You still have to do a commit after these commands. You may make
    any number of new files in your copy of the repository, but they
    will not be committed to the central copy unless you do a 'cvs add'.

OTHER USEFUL COMMANDS AND HINTS

    To see the commit messages for files, and who made them, use:

    cvs log [filenames]

    To see the differences between your version and the central version:

    cvs diff [filenames]

    To give a file a new name, rename it and do an add and a remove.

    To lose your changes and go back to the version from the
    repository, delete the file and do an update.

    After an update where there have been clashes, your original
    version of the file is saved as .#file.version.

    All the cvs commands mentioned accept a flag '-n', that doesn't do
    the action, but lets you see what would happen. For instance, you
    can use 'cvs -n update' to see which files would be updated.

MORE INFORMATION

    This is necessarily a very brief introduction. See the manual page
    (man cvs) for full details.

------------------------------------------------------------------------

From: [e-mail] (B.G. Mahesh)

can I have a look at those sccs tools ? I have installed
cvs. I am thinking of moving to cvs later on.

thanks

--

B.G. Mahesh
[e-mail]

------------------------------------------------------------------------

From: netcon!intime![e-mail]

Actually, you caught me at a good time - I'm in the process of converting
to RCS/CVS. I've found that RCS is less of a straight jacket than SCCS,
and combined with CVS, makes for good concurrent development. If you are
looking at RCS vs. SCCS at a narrow "raw tool" scope, there's not much
to be said, save two things:

    - RCS is easier to learn and use.
      1) You have to use two commands to check a file into SCCS,
         namely admin for the first time, and get for each subsequent.
         RCS uses one command, "ci" (check in).
      2) RCS prompts you for a description of the file. SCCS doesn't
         have this feature.
      3) RCS has fewer keywords to remember.
      4) RCS allows one to associate a symbolic name with a revision
         number.

    - RCS allows one to remove revisions (deltas) that are not the
      ends of a branch. For example, assume a revision path:

       1.1 -- 1.2 -- 1.3 -- 1.4 -- 1.5 -- 2.1 ...
                                        |
                    +- 1.5.1.1 -- 1.5.1.2 ...

      If for the sake of argument, 1.5 is where I released the file
      into production, and I no longer see any need for revisions
      1.2 - 1.4, I can remove them. SCCS won't allow me to do this
      kind of pruning.

With an expanded scope to CVS, a tool built on top of RCS, allows one
to use the symbolic tag feature of RCS to identify releases and products.
CVS also defines a master source repository (where RCS files live), and
the concept of modules (a directory and repository database). This is
infinitely useful since it allows me to pull an individual module (a
component of a product) or an entire product (a whole set of modules).
CVS also works recursively on directories. No such tool exists in the
public domain for SCCS, so you have to roll your own.

Having toiled over the problem for a couple of years, I can say that I
am happy with the choice I made.


------------------------------------------------------------------------

From: [e-mail] (Bryant Eastham)

Hello, my name is Bryant Eastham and I am a system administrator/programmer
at the University of Utah. I have used both SCCS and RCS, although it has
been quite a while since I used SCCS. From my point of view, here are
the benefits of RCS:

   * Multiple platform support - you have the source.
     I have a friend that runs it on his PC at home.

   * Speed. It is faster at extraction than SCCS.

   * Interface. The program seems to have a "cleaner" interface.
     Very easy to write shell scripts that modify things.

   * I cannot remember the features that it has that SCCS doesn't,
     but I know that there are a few.

Hope it helps.
Bryant Eastham
Center for Engineering Design
[e-mail]


------------------------------------------------------------------------
From: Peter Mutsaers <[e-mail]>

RCS has easier commands (but this is no advantage as you're already
familiar with SCCS). The main difference is :
1) It is free and source is available, so you can put it everywhere.

2) You can use symbolic tag names and thus check out an entire
configuration. You tag every file in the current version with a name
and later check this out. (I think this was not available in sccs).

3) You can use the (free) cvs on top of rcs, which manages not only 1
directory, but a whole hierarchy of sources, and is suiteable for very
big projects.


------------------------------------------------------------------------

From: [e-mail] (Lawrence Mulvihill)

Looking forward to your post!


------------------------------------------------------------------------

From: [e-mail] (Paul Eggert)

Here's Bill Wohler's FAQ for your question:

From: [e-mail] (Bill Wohler)
Newsgroups: comp.unix.misc,comp.unix.questions,comp.unix.shell
Subject: Summary: RCS vs SCCS
Message-ID: <[e-mail]>
Date: 2 Jul 92 13:29:12 GMT
Reply-To: Bill Wohler <[e-mail]>
Followup-To: comp.unix.misc
Organization: SAP AG, Walldorf, Germany
Lines: 556

folks,

  since the topic of RCS vs. SCCS comes up every so often, i put
  together some of the responses.  most of my stuff comes from a
  discussion from last year.  the most recent discussion hashed out
  the differences of speed, and didn't add too much new stuff.

  i didn't notice this topic in the faq.  perhaps the faq could
  mention that this summary is available to those who want it (someone
  please volunteer an anonymous ftp site!)

  if you have anything to add, please let me know.  we can use this
  summary if the question pops up again.  sound good?

                *****

The following is a comparison of RCS and SCCS, as well as a
description of a couple of other packages and a bibliography.  This is
a compilation of work from the following people.

    Karl Vogel <[e-mail]>
    Mark Runyan <[e-mail]>
    Paul Eggert <[e-mail]>
    Greg Henderson <[e-mail]>
    Dave Goldberg <[e-mail]>

If you see the word "easier", then be forewarned that this might be
a religious issue.  I've included them just the same.


1.    RCS vs SCCS

The majority of the replies (in a recent poll) were in favor of RCS, a
few for SCCS, and a few suggested alternatives such as CVS.

Functionally RCS and SCCS are practically equal, with RCS having a bit
more features since it continues to be updated.

Note that RCS learned from the mistakes of SCCS...

1.1.    RCS has an easier interface for first time users.  There are less
    commands, it is more intuitive, and provides more useful
    arguments.

1.2.    RCS allows you treat a set of files as a family of files while
    SCCS is meant primarily for keeping the revision history of
    files.    RCS has the ability to use symbolic names to point to
    sets of revisions.

1.3.    RCS keeps history in files with a ",v" suffix.    SCCS keeps history
    in files with a "s." prefix.  Some Make programs recognize the
    "s."  prefix while having trouble with ",v" suffix.  Your
    mileage will vary.

    RCS files are directly editable.  SCCS files should only be
    acted on by the SCCS tools.  (While you *may* edit an SCCS
    file, you will have to recalculate the checksum using the
    admin program.    Also, editing either RCS or SCCS files is a
    bad idea just because mistakes are so easy to make and so
    fatal to the history of the file).

    RCS looks for RCS files automatically in the current directory
    or in a RCS subdirectory.  You have to explicitly name a sccs
    file--annoying.

    RCS stores its revisions by holding a copy of the latest
    version and storing backward deltas.  SCCS uses a "merged
    delta" concept.

    All RCS activity takes place within the single RCS file.  SCCS
    maintains several files.  This can be confusing.

1.4.    Locks are kept in separate files for SCCS.  A lock on an RCS file is
    kept in the RCS file.

1.5.    If you have an RCS file but not RCS, you can still retrieve the
    latest version.     Not true with SCCS.

1.6.    You can translate SCCS to RCS, but not the other way.

1.7.    RCS and SCCS use different keywords that are expanded in the text.
    For SCCS the keyword "%R%" is replaced with the revision
    number if the file is checked out for reading.    In RCS, the
    keyword $Revision$ has the revision number added to it when
    the file is checked out (either locked or not).     The RCS
    keywords are easier to remember.

1.8.    RCS has symbolic names: you can mark all the source files
    associated with an application version with `rcs -n', and then
    easily retrieve them later.

1.9.    SCCS doesn't have an equivalent of rcsmerge (merging changes between
    version a and b into version c).

1.10.    Since RCS stores the latest version in full, it is much faster
    in retrieving the latest version.  After RCS version 5.6, it
    is also faster than SCCS in retrieving older versions.

1.11.    SCCS is supported by AT&T.  RCS isn't.

1.12.    SCCS has more options for determining when a specific line of code
    was added to a system.

1.13.    Command comparison

    Note that when providing a filename to SCCS, one must specify
    the SCCS file, and as the SCCS files are normally in a SCCS
    subdirectory, one must type SCCS/s.file.  In contrast, in RCS,
    one only has to specify the working file name, and the RCS
    filename, in the current directory or in a RCS directory (as
    is common), is automatically generated.

  Here are the commands:

  SCCS                RCS        Explanation
  admin -i -nfile s.file    ci file        Checks in the file for the
                        first time, creating
                        the revision history file.
  get s.file            co file        Check out a file for reading.
  get -e s.file            co -l file    Check out a file for
                        modification.
  delta s.file            ci file        Check in a file previously
                        locked.
  prs s.file            rlog file    Print a history of the file.
  sccsdiff -rx -ry s.file    rcsdiff -rx -ry file    Compare two revisions.
  sccs diffs s.file        rcsdiff file    Compare current with last
                        revision.
  ???                rcs -l file    Lock the latest revision.
  ???                rcs -u file    Unlock the latest revision.
                        Possible to break another's
                        lock, but mail is sent to the
                        other person explaining why.

2.    RCS vs ADC

I've had the the chance to examine ADC and figure out how we might
make some use of it.  The biggest concern I have to date on ADC is the
fact that the company owns the source and contracts out to consultants
to help provide support for the tool (rather than support it
directly).  It appears that the expectation is for you to hire a
consultant who spends a few months setting the tools up with you and
then works with you to make sure that your needs are being met.     RCS
and SCCS at least allow the option for you to examine the source
code...

It uses the concept of change sets.  All changes made to a group of
files is filed as one change set (as you are working, you have an
active changeset).  You have the choice of keeping a set of change
sets to make a release.     This makes it easy to support bug fixes for
particular requests because you can decide to keep or not a set of
changes to make a release.

3.    CVS

                  CVS II:
            Parallelizing Software Development

                  Brian Berliner

                   Prisma, Inc.
              5465 Mark Dabling Blvd.
            Colorado Springs, CO  80918
                [e-mail]

                 ABSTRACT

       The program described in this paper fills a need in the
      UNIX community for a freely available tool to manage software
      revision and release control in a multi-developer, multi-
      directory, multi-group environment.  This tool also addresses
      the increasing need for tracking third-party vendor source dis-
      tributions while trying to maintain local modifications to ear-
      lier releases.

3.1.    Background

In large software development projects, it is usually necessary for
more than one software developer to be modifying (usually different)
modules of the code at the same time.  Some of these code
modifications are done in an experimental sense, at least until the
code functions correctly, and some testing of the entire program is
usually necessary.  Then, the modifications are returned to a master
source repository so that others in the project can enjoy the new
bugfix or functionality.  In order to manage such a project, some sort
of revision control system is necessary.

Specifically, UNIX[1] kernel development is an excellent example of
the problems that an adequate revision control system must address.
The SunOS[2] kernel is composed of over a thousand files spread across
a hierarchy of dozens of directories.[3] Pieces of the kernel must be
edited by many software developers within an organization.  While
undesirable in theory, it is not uncommon to have two or more people
making modifications to the same file within the kernel sources in
order to facilitate a desired change.  Existing revision control
systems like RCS [Tichy] or SCCS [Bell] serialize file modifications
by allowing only one developer to have a writable copy of a particular
file at any one point in time.    That developer is said to have
"locked" the file for his exclusive use, and no other developer is
allowed to check out a writable copy of the file until the locking
developer has finished impeding others' productivity.  Development
pressures of productivity and deadlines often force organizations to
require that multiple developers be able to simultaneously edit copies
of the same revision controlled file.

The necessity for multiple developers to modify the same file con-
currently questions the value of serialization-based policies in
traditional revision control.  This paper discusses the approach that
Prisma took in adapting a standard revision control system, RCS, along
with an existing public-domain collection of shell scripts that sits
atop RCS and provides the basic conflict-resolution algorithms.     The
resulting program, cvs, addresses not only the issue of
conflict-resolution in a multideveloper open-editing environment, but
also the issues of software release control and vendor source support
and integration.

3.2.    The CVS Program

cvs (Concurrent Versions System) is a front end to the RCS revision
control system which extends the notion of revision control from a
collection of files in a single directory to a hierarchical collection
of directories each containing revision controlled files.  Directories
and files in the cvs system can be combined together in many ways to
form a software release.  cvs provides the functions necessary to
manage these software releases and to control the concurrent editing
of source files among multiple software developers.

The six major features of cvs are listed below, and will be described
in more detail in the following sections:

3.2.1.    Concurrent access and conflict-resolution algorithms to guarantee
    that source changes are not "lost."

3.2.2.    Support for tracking third-party vendor source distributions
    while maintaining the local modifications made to those
    sources.

3.2.3.    A flexible module database that provides a symbolic mapping of
    names to components of a larger software distribution.    This
    symbolic mapping provides for location independence within
    the software release and, for example, allows one to check out
    a copy of the "diff" program without ever knowing that the
    sources to "diff" actually reside in the "bin/diff" directory.

3.2.4.    Configurable logging support allows all "committed" source file
    changes to be logged using an arbitrary program to save the
    log messages in a file, notesfile, or news database.

3.2.5.    A software release can be symbolically tagged and checked out at
    any time based on that tag.  An exact copy of a previous
    software release can be checked out at any time, regardless of
    whether files or directories have been added/removed from the
    "current" software release.  As well, a "date" can be used to
    check out the exact version of the software release as of the
    specified date.

3.2.6.    A "patch" format file [Wall] can be produced between two software
    releases, even if the releases span multiple directories.

The sources maintained by cvs are kept within a single directory
hierarchy known as the "source repository." This "source repository"
holds the actual RCS ",v" files directly, as well as a special
per-repository directory (CVSROOT.adm) which contains a small number
of administrative files that describe the repository and how it can be
accessed.

3.3.    Software Conflict Resolution[4]

cvs allows several software developers to edit personal copies of a
revision controlled file concurrently.    The revision number of each
checked out file is maintained independently for each user, and cvs
forces the checked out file to be current with the "head" revision
before it can be "committed" as a permanent change.  A checked out
file is brought up-to-date with the "head" revision using the "update"
command of cvs.     This command compares the "head" revision number with
that of the user's file and performs an RCS merge operation if they
are not the same.  The result of the merge is a file that contains the
user's modifications and those modifications that were "committed"
after the user checked out his version of the file (as well as a
backup copy of the user's original file).  cvs points out any
conflicts during the merge.  It is the user's responsibility to
resolve these conflicts and to "commit" his/her changes when ready.

Although the cvs conflict-resolution algorithm was defined in 1986, it
is remarkably similar to the "Copy-Modify-Merge" scenario included
with NSE[5] and described in [Honda] and [Courington].    The following
explana- tion from [Honda] also applies to cvs:

   Simply stated, a developer copies an object without locking it,
   modifies the copy, and then merges the modified copy with the
   original.  This paradigm allows developers to work in isolation
   from one another since changes are made to copies of objects.
   Because locks are not used, development is not serialized and can
   proceed in parallel.     Developers, however, must merge objects
   after the changes have been made.  In particular, a developer
   must resolve conflicts when the same object has been modified by
   someone else.

In practice, Prisma has found that conflicts that occur when the same
object has been modified by someone else are quite rare.  When they do
happen, the changes made by the other developer are usually easily
resolved.  This practical use has shown that the "Copy-Modify-Merge"
paradigm is a correct and useful one.

3.4.    Tracking Third-Party Source Distributions

Currently, a large amount of software is based on source distributions
from a third-party distributor.     It is often the case that local
modifications are to be made to this distribution, and that the
vendor's future releases should be tracked.  Rolling your local
modifications forward into the new vendor release is a time-consuming
task, but cvs can ease this burden somewhat.  The checkin program of
cvs initially sets up a source repository by integrating the source
modules directly from the vendor's release, preserving the directory
hierarchy of the vendor's distribution.     The branch support of RCS is
used to build this vendor release as a branch of the main RCS trunk.
Once this is done, developers can check out files and make local
changes to the vendor's source distribution.  These local changes form
a new branch to the tree which is then used as the source for future
check outs.

When a new version of the vendor's source distribution arrives, the
checkin program adds the new and changed vendor's files to the already
existing source repository.  For files that have not been changed
locally, the new file from the vendor becomes the current "head"
revision.  For files that have been modified locally, checkin warns
that the file must be merged with the new vendor release.  The cvs
"join" command is a useful tool that aids this process by performing
the necessary RCS merge, as is done above when performing an "update."

There is also limited support for "dual" derivations for source files.
This example tracks the SunOS distribution but includes major changes
from Berkeley.    These BSD files are saved directly in the RCS file off
a new branch.

3.5.    Location Independent Module Database

cvs contains support for a simple, yet powerful, "module" database.
For reasons of efficiency, this database is stored in ndbm(3) format.
The module database is used to apply names to collections of
directories and files as a matter of convenience for checking out
pieces of a large software distribution.  The database records the
physical location of the sources as a form of information hiding,
allowing one to check out whole directory hierarchies or individual
files without regard for their actual location within the global
source distribution.

Consider the following small sample of a module database, which must
be tailored manually to each specific source repository environment:

    #key      [-option argument] directory [files...]
    diff      bin/diff
    libc      lib/libc
    sys      -o sys/tools/make_links sys
    modules      -i mkmodules CVSROOT.adm modules
    kernel      -a sys lang/adb
    ps      bin Makefile ps.c

The "diff" and "libc" modules refer to whole directory hierarchies
that are extracted on check out.  The "sys" module extracts the "sys"
hierarchy, and runs the "make_links" program at the end of the check
out process (the -o option specifies a program to run on checkout).
The "modules" module allows one to edit the module database file and
runs the "mkmodules" program on checkin to regenerate the ndbm
database that cvs uses.     The "kernel" module is an alias (as the -a
option specifies) which causes the remaining arguments after the -a to
be interpreted exactly as if they had been specified on the command
line.  This is useful for objects that require shared pieces of code
from far away places to be compiled (as is the case with the kernel
debugger, kadb, which shares code with the standard adb debugger).
The "ps" module shows that the source for "ps" lives in the "bin"
directory, but only Makefile and ps.c are required to build the
object.

The module database at Prisma is now populated for the entire UNIX
distribution and thereby allows us to issue the following convenient
com- mands to check out components of the UNIX distribution without
regard for their actual location within the master source repository:

3.6.    How to get CVS

It's available via anonymous FTP from prep.ai.mit.edu in
pub/gnu/cvs-1.2.tar.Z.

4.    CMS scripts

If one places the RCS keyword $Id$ into static char arrays in C code,
they end up in the compiled binary.

After I do my checkins and remake the binary, I run a script called
"snapshot" which gives me a nicely-formatted list of the RCS headers.
This makes it easy to check out an entire group of files which are at
different revision levels.

Here is the output of the command "snapshot /usr/bin/cite".

=====================================================================
cite
          cite.c   1.3         1991/11/29     16:59:04  vogel
        getopt.c   1.3         1991/11/29     16:59:47  vogel
         ismailhdr.c   1.2         1991/12/13     20:34:41  vogel
          scanmail.c   1.2         1991/11/29     17:02:01  vogel

A simple awk script can create a series of "co" commands to get
back these versions of each file.  Here is the code for snapshot:

#!/bin/sh
#
#     $Header: snapshot,v 1.2 90/04/12 16:46:01 vogel Exp $
#
#     snapshot:          examines one or more files, and prints RCS header
#              information about each one.  Used to keep track of
#              all of the relevant versions of C functions which
#              make up a working program.
#
#          Usage:  snapshot file [file ...]
#
#     Author: Karl Vogel <[e-mail]>
#

PATH=/bin:/usr/ucb:/usr/bin:/usr/local:/d/cdc/vogel/local
export PATH

BANNER='====================================================================='

case "$#"
in
    0)    echo "usage:  snapshot file [file ...]"          >&      2
        exit 1
        ;;

    *)    for NEXT in $*
        do
            echo $BANNER
            basename $NEXT
            rcsh $NEXT
        done
esac

exit 0

#!/bin/sh
#
#     $Id: rcsh,v 1.5 1991/07/22 18:57:12 vogel Exp $
#
#     rcsh:          takes RCS header strings from either stdin or
#              argument files, reformats them, and prints them
#              nicely.
#
#          Usage:  rcsh [files]
#
#     Author: Karl Vogel <[e-mail]>

PATH=/bin:/usr/bin:/usr/new
export PATH

SED='/\$Id:/s/,v//p
/\$Header:/s/,v//p
'

AWK='{
    sub = substr ($2, 1);

    while ((i = index (sub, "/")) > 0)
        sub = substr (sub, i + 1);

    printf "%30s   %-10s%-12s%-10s%-10s\n", sub, $3, $4, $5, $6
}'

case "$#"
in
    0)    sed -n "$SED" | sort | uniq | awk "$AWK" ;;
    *)    ident $* | sed -n "$SED" | sort | uniq | awk "$AWK" ;;
esac

exit 0

5.    Software Configuration Management literature

General books:

_Software_Configuration_Management_:_Coordination_for_Team_Productivity_,
  by Wayne A. Babich, Addison-Wesley, 1986, ISBN 0-201-10161-0.

_The_Program_Development_Process_, by J.D. Aron, Addison-Wesley, 1983,
  ISBN 0-201-14451-4.

_Software_Configuration_Management_:_An_Investment_in_Product_Integrity_,
  by E. Bersoff, V. Henderson, and S. Siegel, Prentice-Hall, 1980,
  ISBN 0-13-821769-6.

_Proceedings of the International Workshop on Software Version and
  Configuration Control_, edited by Jurgen F.H. Winkler, German Chapter
  of the ACM, Grassau, FRG, January 27-29, 1988.  ISBN 3-519-02671-6

_Proceedings of the 2nd International Workshop on Software Configuration
  Management_, Princeton, New Jersey, Oct 24, 1989.

_Workshop proceedings on Software Management_, USENIX, New Orleans,
  Louisiana, April 3-4, 1989

Papers:

"RCS - A System for Version Control", Walter Tichy, _Software-Practice_and_
  Experience_, Vol 15(7), p637-654, (July 1985).

"Build-A Software Construction Tool", V. Erickson and J. Pellegrin,
  _AT&T_Bell_Lab_Technical_Journal_, Vol 63(6), p1049-1059, (July-August
  1984).

"Design, Implementation, and Evaluation of a Revision Control System",
  Walter Tichy, _IEEE_, Vol ?(?), p 58-67, (??? 1982).

"Project Hygiene", Vic Stenning, _USENIX_Workshop_Proceedings_on_Software_
  _Management_, p1-9, (April 3-4, 1989).

"Software Manaagement Using a CASE Environment", M. Honda and T. Miller,
  _USENIX_Workshop_Proceedings_on_Software_Management_, p11-16,
  (April 3-4, 1989).

"Boxes, Links, and Parallel Trees: Elements of a Configuration Management
  System", Andy Glew, _USENIX_Workshop_Proceedings_on_Software_Management_,
  p17-28(April 3-4, 1989).

"Controlling Software for Multiple Projects", Dale Miller, _USENIX_Workshop_
  _Proceedings_on_Software_Management_, p39-50, (April 3-4, 1989).

"CCSLAND", Nathaniel Bronson III, _USENIX_Workshop_Proceedings_on_Software_
  _Management_, p87-94, (April 3-4, 1989).

"The Release Engineering of 4.3BSD", M. McKusick, M. Karels, and K. Bostic,
  _USENIX_Workshop_Proceedings_on_Software_Management_, p95-100,
  (April 3-4, 1989).

"Rtools: Tools for Software Management in a Distributed Computing
  Environment", H harrison, s. Schaefer, T. Yoo, _USENIX_Conference_
  _Proceedings_, p85-106, (June 20-24, 1988).

"A Schema for Configuration Management", Terrence Miller,
  _Proceedings_of_the_2nd_Int'l_Workshop_on_Software_Configuration_Management,
  October 24-27 1989, Princeton. Published as ACM SIGSOFT Software Engineering
  Notes, Volume 17(8) pp 26-29, November 1989.

_Generic_Software_Configuration_Management:_Theory_and_Design_, by
  Douglas Wiebe, University of Washington, Technical Report 90-07-03;
  published 1990.

"Software Configuration Management of Computer-Aided Design Tools",
  by Peter Nicklin, Hewlett Packard Report DTC-89-01, December 22, 1989.

"Version Control in Families of Large Programs", Juergen Winkler,
  _Proceedings_of_the_9th_International_Conference_on_Software_Engineering,
  Monterey, CA, March 30-April 2, 1987, pp150-161

------------------------------------------------------------------------
From: [e-mail] (Kevin Hintergardt)

We're currently using an in-house SCM program that combines Ingres ESQL with
RCS. RCS was chosen because the reverse deltas are more efficient in the
common cases and source code was freely available so we could link it into
a single executable instead of shelling out SCCS commands. RCS also had
some neat interrupts handling code we shanghied (sp) to solve interrupt
shortfalls with Ingres FRS (forms).

In case your real new to SC, the RCS reverse deltas keep the MOST RECENT
copy intact and stores deltas (really sed edit commands) to recreate old
versions if needed. SCCS maintains the ORIGINAL intact and must process
all forward deltas to get the most recent version. Since programmers
usually want the most recent version. Reverse deltas are more efficient.
RCS still uses forward deltas for branch versions and it always branches
from the most recent root version.

I've been on programs that use SCCS raw, SCCS with a front-end, self-
generating csh scripts (yuk) and this RCS/Ingres approach. The latter
is the only approach where I haven't heard programmer complaining about
slow checkin/checkout, complexity, or lack of features. It does have
about 20,000 line of C to integrate together but if we need an extra
validation check or more control over the 200+ programmers, we can do it.
Not that I'm bias or anything. For a project our size, the dedicated
tool builder (me) was justifiable.  I dont know what your situation is.

            [e-mail]








































--
/------------------------------------------------------------------\
|     David B. Andersen             ([e-mail])           |
\------------------------------------------------------------------/