eric@osiris.UUCP (Eric Bergan) (04/30/85)
I realize that this has probably been discussed before, but please bear with me. We are embarking on several large software development efforts, which need the security a code control system offers. What we would like to know is the relative benefits of RCS vs. SCCS. Is one overwhelmingly better than the other? Are there any hidden "features" we should be aware of? What have everyone's experiences been in using one system of the other? I will summarize all results to the net. Thank you. -- eric ...!seismo!umcp-cs!aplvax!osiris!eric
eric@osiris.UUCP (Eric Bergan) (05/06/85)
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@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@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@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!ericcpc@AMES-NAS.ARPA (Chuck Collins) (05/07/85)
I talked to Walter Tichy not too long ago, and he insists that RCS is NOT public
domain. It is distributed with BSD source, but that doesn't give one the right
to give the source to others. Also, part of RCS is covered by AT&T source
license. Perhaps we could get a definitive statement from the author?
Chuck Collins cpc@ames-nas {ihnp4,hplabs}!ames!amelia!cpcphil@amdcad.UUCP (Phil Ngai) (05/08/85)
We ran into an issue here at AMD which Eric Bergan's summary did not really cover. Some people touched on the issue but I believe they are wrong. I hope I am wrong but I did ask Tichy and unless I misunderstood him, there are some disadvantages which make RCS less preferable. These disadvantages are more legal than technical but can not be ignored. To start with, RCS is *not* public domain. Tichy owns it and in addition it is contaminated with ATT code (parts of diff). Therefore you need a source license to legally have RCS source. You need a binary distribution license to distribute binaries. And, Tichy does not permit (I believe) people to sell or otherwise make profit off his code. On the other hand, SCCS comes with System III or V. Free. No extra work. We have a couple of CPUs licensed for source and RCS is just fine there. We have a lot of Unix workstations with binary licenses from various vendors. Guess what came with them? That's right, SCCS. Not RCS. I think Tichy's use restrictions are why the vendors did not include RCS. I believe we are not allowed to put the RCS source on our non-source licensed workstations and compile it and run the binaries. I also believe we are not allowed to just buy source for one workstation, compile binaries, and put them on all the other workstations unless we buy a binary distribution license, even to distribute to ourselves. It would be very easy to cheat and do it anyway but that is not how we operate. Since it is a pain to switch back and forth between systems we have to chose the inferior system because it is more widely available. I doubt this is what Tichy intended, but that's how it works out. I would be happy to hear of vendors such as Sun who do include RCS. In article <308@osiris.UUCP>, eric@osiris.UUCP (Eric Bergan) writes: > From: Craig Partridge <umcp-cs!seismo!craig@loki.ARPA> > (1) RCS is sort of in the public domain. (I think Tichy claims > some minor rights). SCCS isn't. Nope, it's contaminated with ATT code and Tichy owns the rest. > From: umcp-cs!seismo!arnold@ucsf-cgl.ARPA (Ken Arnold) > 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. Nope, it requires a Unix source license to have it. > 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. Guy, does Sun offer it? If not, why not? -- I speak for myself and no one else. Phil Ngai (408) 749-5720 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.ARPA
arnold@ucsfcgl.UUCP (Ken Arnold%CGL) (05/09/85)
>From: Craig Partridge <umcp-cs!seismo!craig@loki.ARPA> > (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. This is a common piece of misinformation. RCS does store backward delta's, i.e., it stores the current version intact, and has deltas backwards to get earlier version. However, SCCS does NOT store forward deltas from the original. It uses in-line deltas, giving a fixed one-pass overhead to get different deltas. Thus, getting the current version is slightly slower (I believe the figure is around 5% slower than RCS), but getting the version one delta back (for doing a diff, say), SCCS is faster by a small amount, and for anything more than one delta, SCCS is MUCH faster. In other words, to get a delta N deltas back from the top, it takes one pass for SCCS and N passes for RCS. None the less, I do prefer RCS, as you know if you read father into the summary to get my comments. This particular piece of "slander" against SCCS should be cleared up. It is unfortunate that RCS doesn't use this technique.
guy@sun.uucp (Guy Harris) (05/09/85)
> I think Tichy's use restrictions are why the vendors did not include RCS. I believe your statements about putting RCS on your other machines are probably correct, but that wouldn't restrict vendors from offering RCS. They already distribute binaries of "diff" with their machines, so they could also distribute binaries of "rdiff". I asked Tichy about distributing RCS a while back (when I was at CCI - we weren't distributing it as part of our system, even though we'd ported it and were using it heavily, because we weren't sure what restrictions Tichy had put on redistribution) and I think he said that you could redistribute it (in binary form) as part of a system if you were distributing binary UNIX sublicenses with the system. > Guy, does Sun offer it? If not, why not? No, we don't offer it, nor do we use internally (sigh). (We do use the SCCS front end, which does sugar-coat it somewhat.) We don't offer any of the 4.2BSD User Contributed Software except for netnews (I don't think we should be distributing that, since it's the 2.10.2 that came with 4.2BSD and may still have the line-eater bug, and since other people are already in the "business" of distributing it). I suspect it's either 1) because somebody made a policy decision not to redistribute that stuff because it'd add to our support burden or something like that or 2) because nobody ever brought it up and nobody felt like spending the effort to bring it up. Guy Harris
seifert@hammer.UUCP (Snoopy) (05/10/85)
In article <1271@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes: >I would be happy to hear of vendors such as Sun who do include RCS. > Phil Ngai (408) 749-5720 > UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil > ARPA: amdcad!phil@decwrl.ARPA The "Auxiliary Utilities" package for Utek includes RCS. Snoopy tektronix!mako!seifert