RCS vs SCCS (RESULTS - LONG)

[Eric Bergan]

	I have gotten several replies to my original posting, including
some compendiums from earlier queries about the same issue. Below is
a sampling of the answers. No one who had used both recommended SCCS over
RCS.

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


From: Craig Partridge <umcp-cs!seismo!craig at loki.ARPA>

I think the general view is that RCS is better.  It is certainly my
view.  Here are my reasons:

	(1) RCS is sort of in the public domain.  (I think Tichy claims
	some minor rights).  SCCS isn't.

	(2) RCS does everything SCCS does (or did last time I checked).

	(3) RCS is faster.  RCS stores diffs to take you back from the
	most recent edition of the source.  SCCS stores changes forward
	from the first version.  So in SCCS you wait a while for
	your current file to retrieved.  In RCS there is no wait.

	(4) Personally I find the RCS interface more intuitive,
	even though I think the interface differences are minor.

From: Chuck Collins <umcp-cs!seismo!cpc at AMES-NAS.ARPA>

I have been working with RCS since last fall. I built a custom configuration
management tool for controlling numerous baselines of sources for numerous
machines for a large project at Ames Research. My tool is essentially a
front end, the back end of which is RCS. Subsequently, I ported the tool
to a machine without RCS, using SCCS instead. So I am familiar with the
differences in this context.

To give you an indication of how I feel about it, I wish I had a nickel for
everytime I've typed:

	get control.c

followed by

	get s.control.c

SCCS has a user interface that would make an MVS program proud, since indeed
that is where SCCS came from. In general, as I was learning RCS, I kept on


From: <umcp-cs!seismo!ut-sally!oakhill!mot!fred>

for maintaining the complete source of Unix System V for M68000 and for
many other projects, we use SCCS and have had no problems that i am aware of.
since we do not have RCS, i cannot offer a comparison.
	note that, to improve the security of SCCS, we use a set of front-end
tools, setuid-to-<magic name>, where <magic name> only has access to the files.
these tools have been described in recent issues of Computer Languages magazine.

From: umcp-cs!seismo!hadron!tsp (T. Scott Pyne)

  We have used both SCCS and RCS at Hadron for large (order of 5 person-year)
software development efforts within the past year.  The projects using SCCS
were done under Xenix 2.3; the projects using RCS, under 4.2BSD.  Our exper-
ience indicates that RCS is preferable, but not absolutely mandatory, on such
projects, for several reasons.  In no particular order, here they are:
  Integration of RCS with make (so make can check out a copy of something if
it isn't already checked out and available) is easier than with SCCS.  The RCS
filename syntax fits in well with make's dependency-calculation approach; the
"s." prefix convention of SCCS does not.  I have used the S/III and S/V make
which understands prefixes, but for my money RCS and make still get along bet-
ter.  In any case, the make we had under Xenix was V7, with none of the prefix
handling stuff.
  We perceive an advantage to RCS since it does not use non-printing characters
in its archive file. (SCCS uses ^A to mark its control lines.)  A minor point.
  RCS is much more intelligent about handling keyword substitution, in our opin-
ion.  SCCS barfs and gags if you check in, uh, delta, a file which has had the
SCCS "keywords" already substituted.  So, if you accidentally get a file with-
out the '-e' flag, modify it, and try to delta it back in, SCCS bitches about
"No ID keywords".  RCS, on the other hand, keeps the keyword itself in place
when it is expanded, so checking in a file with alreeady-expanded keywords is
no problem.  (In fact, RCS always expands keywords upon checkout, for editing
or otherwise.)  This issue would never come up if all of our people were per-
fect, but after 2 or 3 times of accidentally doing "get s.foo.c;vi foo.c;delta
s.foo.c" and realizing one had screwed up, RCS' forgiving nature is welcome.
(Yes, I also know about SCCS' approach to file permissions....)  Not to mention
the fact that RCS uses real *keywords* instead of %X%.  The meaning of %G% %U%
is nowhere near as obvious as $ Date: $.
  RCS' ability to associate names with rev levels is nice, and I have found no
counterpart in SCCS.  When an old version of a package needs to be remade, it
is easier to do "co -rlitton" than "get -r2.7 s.foo.c; get -r3.9 s.bar.c; ..."
(When we send a version of a package out the door, we check the sources in
all at once with the same name, as in "ci -ncustomer_name *.c *.h".  RCS is
also nice in that it will ask you if you want to reuse the first log entry
for subsequent checkins when multiple files are passed to a single ci.
  From a functional viewpoint, SCCS stores the root of the archive tree and
change sets for subsequent revisions, while RCS stores the most recent revision
verbatim and changes to work back to older versions.  Probably insignificant
unless you are worried about time to do the archive updates and retrievals.
  Last, our group seems to prefer the command structure and argument syntax
of RCS.  It is (seems?) simpler and more orthogonal.  The fact that RCS will
also automatically use the directory ./RCS for archive files is also nice,
in our opinion.  SCCS will not do this automatically, one must do things like
"delta SCCS/s.foo.c".  We like the idea of keeping the archive files from
cluttering up a source directory.
  The bottom line:  either one will suffice, but we prefer RCS.  We are more
productive with RCS; it seems to fit in better with our software engineering
approach; and I hear fewer bitches about using it (none, in fact) than about
SCCS.  We use RCS exclusively anywhere it is available, even if SCCS is 
available on the same machine.
  I apologize for being so verbose, but I hope this is of benefit.  Good luck,
whichever you choose.

From: umcp-cs!seismo!arnold at ucsf-cgl.ARPA (Ken Arnold)

SCCS has a lousy user interface, unless you get the sccs front end
written by Eric Allman at Berkeley.  I believe this is available with
4BSD, but I'm not sure.

Otherwise, SCCS and RCS are roughly equivalent. However, RCS puts its
files in a subdirectory, and keeps them out of your way.  the sccs
front end will do that for you, but without it, SCCS keeps everything
in the same directory, which is a pain.  RCS also works a bit better with
make, since it uses a suffix instead of a prefix to indicate its files.

The other advantage of RCS is that it is more portable, since it doesn't
require a special license from Bell, and is, unless I am much mistaken,
public domain.  This means that, if you want to send source around, you
can send them RCS if they don't already have it.

From: ihnp4!pur-ee!ef:malcolm (Malcolm Slaney)

I used SCCS back in 1978 or so when I was working with at IH.  I found
it to be an awful pain and not especially fun to use.  To sum up
my impression of SCCS, it was more trouble than it was worth.  The
SCCS package I was using had a whole bunch of shell scripts grafted
on top of SCCS and that only made things half palatable.

I've been using RCS since it first came out and I have found RCS a
joy to use.  I use RCS for everything I do.  It is very painless to
use and has saved me countless of hours.

From: ihnp4!aurora!eugene (Eugene miya)

The only real advantage is the improved SCCS has a somewhat better
make.

RCS is simpler in design and easier to understand and use.  This latter
includes things like file descrepancies (user problems) when they occur
(like a user checks a file in when he or she didn't really mean to).
There are a fair number of GCOS file system features which appear to
be hold overs from earlier days.  The UCB front end to SCCS makes the
SCCS system more useable, but I still prefer RCS.  Oh, performance,
since RCS keeps reverse diffs, if you are working with the most recent
versions, you save on check out time {since SCCS uses forward diffs}.

We have since dropped the use of SCCS including the Berkeley front end.
If you have any specific questions, I am open.  We didn't take any stats,
but you can contact Walter Tichy as he did the comparison work with RCS
(developer) and SCCS.

From: Guy Harris <ulysses!seismo!rlgvax!guy>

Well, we haven't used SCCS much, but what I've seen of it leads me to
believe that RCS meets our needs better than SCCS.

SCCS has a *lot* more "features" than RCS, but either we've never spent
the time to learn enough about them to make them useful or they really
aren't useful.  RCS has one *very* nice feature that I don't think
SCCS has - you can stamp a "symbolic version number" on a version of
a file.  This means that if you have, say, a program made out of five
source files, and you've just checked in, built, tested, fixed, checked in
again, ... Version 1.1 of that program, and you've just frozen it for
release, you can stamp the current RCS version of that with the symbolic
name "V1_1".  This means you can check out the Version 1.1 source by
saying "co -rV1_1 ...".

>From what little playing I've done with SCCS, RCS seems easier to use - in
part because it isn't so feature-laden.  You can check out the latest
version of a file faster using RCS than using SCCS, because RCS stores the
latest version and "backward differences" giving the earlier versions, rather
than storing the initial version and "forward differences" as does SCCS.
RCS doesn't store branches this way, however; I don't know which one can
apply a given set of differences faster.

Being able to give the plain file's name (which RCS lets you do) rather
than the SCCS file's name is nice.  It's also nice to be able to stick
the RCS files in a subdirectory called RCS and not have to give the "RCS/"
when checking out/in.  Our operating system source has all the RCS files
on a separate file system, and the RCS "subdirectories" are actually
symbolic links.

-- 

					eric
					...!seismo!umcp-cs!aplvax!osiris!eric