SCCS vs RCS

[Gary S. Trujillo]

>/ mark at ria-emh2.army.mil (Mark D. McKamey IM SA) /  7:36 am  Jun  6, 1989 /
>     I am currently looking into implementing a revision control program
>for numerous source files here locally.  I am somewhat familiar with AT&T's
>SCCS program, but have heard of a program called RCS (Revision Control System)
>by Purdue University.  ...

[discussion begun in comp.unix.questions - being cross-posted to
comp.unix.wizards for purposes of informed discussion]

I just joined this discussion, so I don't know if it's already been mentioned,
but I wanted to point out that Eric Allman has written an article comparing the
two systems in the March '89 issue (vol. 7, no. 3) of _UNIX_Review_ magazine
in the "C Advisor" column (p. 72 ff).  In the concluding section of the article
[quoted from without permission], Eric says:

	One more important question must be asked:  Which one should
	you use?  As always, the answer is: it depends.  SCCS is older
	and generally more mature.  In my opinion, many of the funda-
	mental design elements of SCCS are superior to those of RCS.
	For example, I have seen RCS trash master files when the disk
	ran out of space at inopportune times, and RCS is much more
	cavalier about writing the master file than is SCCS.
	Specifically, SCCS does not rewrite the master file when you
	check out a file, changing it only when you check a new
	version in.

	All the same, the user interface of RCS is on the whole much
	nicer.  RCS allows for the naming of versions, whcih is very
	useful when you have several files in one directory that make
	up a single system.

	RCS also assigns a *state* to each version, such as
	"Experimental" or "Release".  This simplifies release
	management somewhat.  It has been my experience, however, that
	in very large systems (several hundred files in several
	directories) more sophisticated version and release management
	is necessary.  In such cases, the additional maturity of SCCS
	wins the day.

	My final conclusion is that, for medium-sized systems, RCS is
	still the easiest way to go.  For large systems, where release
	mechanisms will likely have to be built anyway, SCCS is
	probably better.  For small systems, it is really a toss-up.

	Of course, if you don't have SCCS--which, like everythying
	else from AT&T, is licensed and fairly expensive--the decision
	is an easy one.

[The rest of Eric's article is really a brief tutorial on the use
of each, and doesn't have much to say about which might be better for
a specific purpose.]

	(Eric Allman is a senior programmer at the International
	Computer Science Institute, a research organization in
	Berkeley, California, where he is learning about neural
	networks and new technologies.  He previously worked at
	Britton Lee Inc. and on the INGRES project at the University
	of California at Berkeley.  He is the author of sendmail and
	of the -me macros, among other contributions to BCS UNIX.)

	_UNIX_Review_ (with which I have no connection, except as
	a satisfied reader) is published monthly by Miller Freeman
	Publications Co.  [ISSN-0742-3136]
	
	Their snailing address is:

		UNIX Review
		500 Howard Street
		San Francisco, CA 94105

	Email may be sent to:

		{uunet,mtxinu,basis,attmail}!beast!editor


Another good source on the subject is the article by Walter F. Tichy, the
author of RCS, published in the Proceedings of the IEEE 6th International
Conference on Software Engineering (Tokyo, 1982).  The article seems to
make a good case for the superior efficiency and performance of RCS,
which seems due largely to the fact that most checkouts are of most-
recent versions, which RCS can do quickly since it uses the scheme of
storing the most recent version of files (incorporating embedded
control information), and applies reverse deltas if older versions are
requested.	 [0270-5257/82/0000/0058$00.75 (c) 1982 IEEE]


I post this information hoping to promote some further discussion on the
subject.  I plan to undertake the use of one of the two systems on a
major project within the next month, and would like to hear stories and
opinions by users of one or both.

-- 
	Gary Trujillo
	(harvard!wjh12!gst)