SCCS vs. RCS (was: RCS for System V)

[Greg Woods]

>I wrote:
>> I find SCCS is by far the more powerful and capable of the two.

In article <3435 at phri.UUCP> roy at phri.UUCP (Roy Smith) writes:
>
>	Spoken like somebody who has used both of them and is thus in a
>position to "compare and contrast".  Please do -- unsupported "X is better
>than Y" statements leave the reader cold.

[ I received a similar note in the mail, but I not only had to re-send
my reply several times because of bounces, I've also lost my local copy
of it!  So here goes with a re-write.  Hope nobody dozes off. ]

First, I've seen a few discussions about this very topic, and since I
don't >>always<< like to repeat things already said, I didn't embark on
a full explanation :-).  [ Besides, I rather enjoy being terse the first
time around.  Then I can say I-told-you-so, or, you-asked-for-it! ]

Confession:  I've only used RCS in a trivial manner, and never for an
entire large project.  I have, however, used Polytron VCS for a very
large project.

For those who don't know, Polytron VCS is an RCS clone for MS-DOS, VMS,
and (RSN) Unix; with a few additions and deletions in the features
category.  It is not file-format compatible with RCS, nor SCCS, nor with
and other system I know of (maybe it itsn't an RCS clone, though it sure
seems like one when you use it!).  For the most part, my discussion of
RCS applies to VCS.  VCS has a slightly better directory management
scheme, and it is fully integrated into Polytron Make as well (at least
after I got through with "builtins.mak" it was!).  Since I last used it,
Polytron have added a neat-o forms/menu driven full-screen front-end to
VCS.  It seems this feature is an un-shakeable requirement in the DOS world.

Support:  I have used SCCS in several large projects, and I use it to
track all local modifications to Usenet and other outside sources.

Disclaimer:  I use Eric Allman's sccs front-end driver.  With it, and a
couple of aliases, I can make SCCS appear very much like RCS, and make
it just as easy to use.  My reason for doing so, besides the inherit
ease of use, is to allow the stuffing of all those hideous s-file's and
p-file's into a subdirectory.  At one time, RCS's automatic capability
to do so with it's database files was a major attraction.

SCCS disadvantages:  For me, SCCS is only missing one necessary feature,
and one handy feature:  1.  No "automatic" capability to mark a set of
files with a "version" (as opposed to revision) tag.  2. No "state" tag.

[ HELP!  Anyone know how to USE vc?  I think it can be used to do this. ]

Both of these are very similar, and one might wonder why RCS provides
both when simple naming conventions with (1) can probably satisfy the
requirements that may have driven the creation of (2).  At least we did
quite well without (2) using VCS.  I'm not sure if VCS has (2) or not.
We didn't use it.

Of small note, and of complete indifference to me, is SCCS's in-ability
to include the comments, MR numbers, and other interesting information
(that the prs command is able to extract and display from the s-file)
into the g-file (actual source).  It is slightly annoying that the get
keyword list is slightly different, and much restricted, in respect to
that of prs.  Although I haven't examined all of the possible
collisions, I believe this situation could be rectified quite easily.

Also of complete indifference to me is the relatively steep learning
curve for SCCS (I know it all :-).  To offset this, there is a simple
online help facility (more of a reminder service).  It is aptly named
'help' :-).  (In case you didn't guess, this is also a disadvantage.)

This isn't really a disadvantage any more, but old versions of SCCS
silently truncated filenames, if the s. prefix made them too long.  This
is now an error, and if you want to store this file with SCCS, you'll
have to come up with a shorter name.  I've no experience with RCS's
handling of names-too-long (BSD allows wonderfully long names).  If it
does nothing, it could be in more danger, cause it put's it "id" on the
tail of a filename.

SCCS Advantages:  Despite claims to the contrary, I feel the SCCS id
keyword syntax is quite easy to learn, and very useful.  I can include
as much, or as little, information about the file, and current revision,
as I care to, and in almost any context.  Keyword expansion can be
turned off, and often "escaped" to prevent expansion.

SCCS seems to allow much more flexible merging of revisions.  A list,
and/or range(s) of revisions can be specified to be included, or
excluded from a get.  Rcsmerge seems to allow only two revisions to be
merged.  I suppose a script of Rcsmerge's could eventually accomplish
the same result, with a lot more care.  Both systems mark conflicting
changes.

SCCS is, in fact, more flexible than RCS in dealing with sub-
directories.  Not only can directory names be specified on the command
line of any SCCS member program, so can it read a list of files (and
possibly directories, I haven't checked) from stdin!  Along with a
suitable driver, such as the aformentioned sccs, file manipulation is a
piece of cake!

RCS Disadvantages:  (Other than those implicitly mentioned above.)  RCS
keywords are very limited, and cannot be disabled.

RCS Advantages:  (Other than those implicitly mentioned above.)  I
believe, though I haven't actually verified this, that RCS will allow
infinite branching; ie: you could have a revision 1.1.1.1.1.1.1.1.1.1.1.
SCCS is much more limited in its world view, and only allows release,
level, branch, and sequence id's: ie: only 1.1.1.1.  RCS seems to allow
zero (0) as a revision component.  I haven't had any success getting
SCCS to use such.

RCS will automatically create the database when using ci, or it can be
done explicitly with rcs, (ala admin in SCCS).  Who cares?  So can a
fastidious driver program using SCCS (unlike sccs), as did the shell
scripts I wrote and used before using sccs.

According to something I read in the RCS manuals, RCS "simplifies
software distribution ... [such that] ... customer changes can be merged
into distributed versions locally, or by the development group".  This
probably isn't as easy as it implies.  It certianly isn't that easy with
SCCS.  At least not without L. Wall's Patch utility.  I've never tried
such a feat without it.  The sccs driver leaves something to be desired
when creating context diffs too.  I can't find anything in the RCS
manuals to replace patch, so you probably need it when using RCS too.

>	Me?  I'm a true-blue RCS fan (RCS vs. SCCS has to rank up there
>with Sys5 vs. BSD and emacs vs. vi for silly religious wars).  I find RCS
>basicly does everything I need to do.  On the other hand, if somebody could
>show me why SCCS is better in concrete terms, I might consider changing my
>mind.  I guess that means I not a True Believer.

You're right.  For the most part, in general use, RCS will do everything
you need it to, and more.  However, SCCS is a standard tool, and, in my
view, provides more functionality and power than RCS.  (I know, W. Tichy
tried to make RCS standard by putting it on the BSD tape.  Too bad he
still charges a license fee, and too bad he didn't try/succeed in
selling it to AT&T.  If it was PD, I'm sure it would win hands down.
AT&T might even have picked it up too.)

[ Why have I seen RCS advertised for annonymous ftp (and UUCP?) lately.
Has the license been voided?  Is this only for BSD source licensee's? ]

In my case, it's not a religious war.  I have both at my finger tips.  I
spent lots of time and effort making VCS work, and I liked the results.
Then I tried SCCS, 'cause nobody had RCS for Xenix.  I had enough bad
experiences with SCCS to try RCS again when I could.  RCS lost.  VCS
would lose too, except it has no competition (that I have any experience
with) in the MS-DOS world.  RCS watch out, VCS is coming to a system
near you ;-).

BTW:  I like Sys V, and emacs (in particular, Jove).  Hope this allows
all concerned to categorize me and dismiss my remarks I don't fit their
mold.

[ roy at phri.UUCP (Roy Smith) signed article <3435 at phri.UUCP>: ]
>-- 
>Roy Smith, System Administrator
>Public Health Research Institute
>{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy at uunet.uu.net
>"The connector is the network"

In short, (I know, I wasn't) SCCS is the more capable, flexible, and
powerful of the two.  Admittedly it is hard to learn, and in some cases,
hard to use, but isn't everything that's more powerful and flexible? :-)

[ How's that for tootin' your own horn?  Ok, everyone, WAKE-UP! ]

[ Roy:  I was going to say "Don't you like Sun?", but on further
reflection of your quote, I see that Sun's "motto" follows directly from
it. ]
-- 
						Greg Woods.

UUCP: utgpu!woods, utgpu!{ontmoh, ontmoh!ixpierre}!woods
VOICE: (416) 242-7572 [h]		LOCATION: Toronto, Ontario, Canada