by 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 <vo...@c-17igp.wpafb.af.mil>
Mark Runyan <run...@hpcuhc.cup.hp.com>
Paul Eggert <egg...@twinsun.com>
Greg Henderson <hend...@infonode.ingr.com>
Dave Goldberg <d...@mbunix.mitre.org>
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
berli...@prisma.com
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 <vo...@c-17igp.wpafb.af.mil>
#
PATH=/bin:/usr/ucb:/usr/bin:/usr/local:/d/cdc/vogel/local
export PATH
BANNER='=================================================================== case "$#" *) for NEXT in $* exit 0 #!/bin/sh PATH=/bin:/usr/bin:/usr/new SED='/\$Id:/s/,v//p AWK='{ while ((i = index (sub, "/")) > 0) printf "%30s %-10s%-12s%-10s%-10s\n", sub, $3, $4, $5, $6 exit 0 5. Software Configuration Management literature General books: _Software_Configuration_Management_:_Coordination_for_Team_Productivity_, _The_Program_Development_Process_, by J.D. Aron, Addison-Wesley, 1983, _Software_Configuration_Management_:_An_Investment_in_Product_Integrity_, _Proceedings of the International Workshop on Software Version and _Proceedings of the 2nd International Workshop on Software Configuration _Workshop proceedings on Software Management_, USENIX, New Orleans, Papers: "RCS - A System for Version Control", Walter Tichy, _Software-Practice_and_ "Build-A Software Construction Tool", V. Erickson and J. Pellegrin, "Design, Implementation, and Evaluation of a Revision Control System", "Project Hygiene", Vic Stenning, _USENIX_Workshop_Proceedings_on_Software_ "Software Manaagement Using a CASE Environment", M. Honda and T. Miller, "Boxes, Links, and Parallel Trees: Elements of a Configuration Management "Controlling Software for Multiple Projects", Dale Miller, _USENIX_Workshop_ "CCSLAND", Nathaniel Bronson III, _USENIX_Workshop_Proceedings_on_Software_ "The Release Engineering of 4.3BSD", M. McKusick, M. Karels, and K. Bostic, "Rtools: Tools for Software Management in a Distributed Computing "A Schema for Configuration Management", Terrence Miller, _Generic_Software_Configuration_Management:_Theory_and_Design_, by "Software Configuration Management of Computer-Aided Design Tools", "Version Control in Families of Large Programs", Juergen Winkler, Bill Wohler <woh...@sap-ag.de> <sapwdf!wohler>
in
0) echo "usage: snapshot file [file ...]" >& 2
exit 1
;;
do
echo $BANNER
basename $NEXT
rcsh $NEXT
done
esac
#
# $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 <vo...@c-17igp.wpafb.af.mil>
export PATH
/\$Header:/s/,v//p
'
sub = substr ($2, 1);
sub = substr (sub, i + 1);
in
0) sed -n "$SED" | sort | uniq | awk "$AWK" ;;
*) ident $* | sed -n "$SED" | sort | uniq | awk "$AWK" ;;
esac
by Wayne A. Babich, Addison-Wesley, 1986, ISBN 0-201-10161-0.
ISBN 0-201-14451-4.
by E. Bersoff, V. Henderson, and S. Siegel, Prentice-Hall, 1980,
ISBN 0-13-821769-6.
Configuration Control_, edited by Jurgen F.H. Winkler, German Chapter
of the ACM, Grassau, FRG, January 27-29, 1988. ISBN 3-519-02671-6
Management_, Princeton, New Jersey, Oct 24, 1989.
Louisiana, April 3-4, 1989
Experience_, Vol 15(7), p637-654, (July 1985).
_AT&T_Bell_Lab_Technical_Journal_, Vol 63(6), p1049-1059, (July-August
1984).
Walter Tichy, _IEEE_, Vol ?(?), p 58-67, (??? 1982).
_Management_, p1-9, (April 3-4, 1989).
_USENIX_Workshop_Proceedings_on_Software_Management_, p11-16,
(April 3-4, 1989).
System", Andy Glew, _USENIX_Workshop_Proceedings_on_Software_Management_,
p17-28(April 3-4, 1989).
_Proceedings_on_Software_Management_, p39-50, (April 3-4, 1989).
_Management_, p87-94, (April 3-4, 1989).
_USENIX_Workshop_Proceedings_on_Software_Management_, p95-100,
(April 3-4, 1989).
Environment", H harrison, s. Schaefer, T. Yoo, _USENIX_Conference_
_Proceedings_, p85-106, (June 20-24, 1988).
_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.
Douglas Wiebe, University of Washington, Technical Report 90-07-03;
published 1990.
by Peter Nicklin, Hewlett Packard Report DTC-89-01, December 22, 1989.
_Proceedings_of_the_9th_International_Conference_on_Software_Engineering,
Monterey, CA, March 30-April 2, 1987, pp150-161
Heidelberg Red Barons Ultimate Frisbee Team