Summary: RCS vs SCCS

Summary: RCS vs SCCS

Post by Bill Wohl » Fri, 03 Jul 1992 22:29:12


  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 <>
        Mark Runyan <>
        Paul Eggert <>
        Greg Henderson <>
        Dave Goldberg <>

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

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

        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
  delta s.file                  ci file         Check in a file previously
  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
  ???                           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

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


           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

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

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

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 in

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.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:

#     $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 <>  

export PATH


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

        *)    for NEXT in $*
                        echo $BANNER
                        basename $NEXT
                        rcsh $NEXT

exit 0

#     $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 <>  

export PATH


        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 "$#"
        0)    sed -n "$SED" | sort | uniq | awk "$AWK" ;;
        *)    ident $* | sed -n "$SED" | sort | uniq | awk "$AWK" ;;

exit 0

5.      Software Configuration Management literature

General books:

  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.

  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


"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

"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,
  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,
  Monterey, CA, March 30-April 2, 1987, pp150-161

Bill Wohler <> <sapwdf!wohler>
Heidelberg Red Barons Ultimate Frisbee Team


1. Summary: RCS vs SCCS (Correction)

[Note: I received this correction to my previous summary - Greg]

In comp.unix.misc you quote somebody as saying:

This old rumor is false.  SCCS stores code in an interleaved format:  a single
pass through the SCCS file is sufficient to extract any revision.  Although
RCS's method of storing revisions is faster for the typical case of retrieving
the most recent revision, RCS must access the history file at random when
retrieving older revisions.  In my experience, RCS is usually faster than SCCS,
but the cost tradeoffs are more complicated than the misinformation quoted
above would imply.


2. Diamond Stealth 3D 2000 and X

3. Summary: RCS .vs. SCCS

4. when root, why does w show "-"?

5. Summary of SCCS document references (and RCS too)

6. Linux in Industry #1

7. rcs vs. sccs

8. User Access

9. sccs vs. rcs

10. Quest: RCS vs. SCCS

11. SCCS vs RCS

12. RCS .vs. SCCS

13. SCCS vs RCS