[comp.unix] Summary: SCCS vs. RCS

louk@tslwat.UUCP (Lou Kates) (11/09/90)

The following describes the relative advantages and disadvantages
of SCCS vs. RCS. The * indicates which of the two on each line is
preferable. In  lines without a *,  there is either no difference
or   preference   will   depend   on  your  particular needs  and
circumstances.

Item            SCCS                          RCS

custom header   yes*                          no
change requests yes*                          no
make            understands SCCS*             does not understand RCS
setuid          yes*                          no

user interface  worse                         better*
symbolic tags   no                            yes*
loc'n of revs   current directory             any directory*
rev history     stored in SCCS                can be copied to file on checkout*

speed           retrieve old versions faster  retrieve latest version faster
distribution    binary from UNIX vendor       source from Purdue or GNU
free front ends sccs                          CVS
usually used in System V                      BSD

The above list may change over time as SCCS and RCS are improved.
In particular,  apparently,  setuid on  certain platforms and the
ability to retrieve older versions faster  will be in the next or
future versions of RCS.

The disadvantages  with either  can often  be overcome by using a
simple shell (possibly even just a  csh or ksh alias) front  end.
Several freely available front ends exist.

Perhaps one of  the  points in the  table above is enough to make
you choose one  of the two systems  but my sense of the  response
was that  RCS  and SCCS  are sufficiently similar  that you would
probably  be guided  by   what was most available and familiar to
you which means SCCS on System V and RCS on BSD.


WHERE TO GET

RCS is  available  on arthur.cs.purdue.edu.  If you have problems
contact rcs-bugs@cs.purdue.edu. An MS-DOS version is available on
wsmr-simtel20.army.mil in

        PD1:<MSDOS.PGMUTL>DOSRCSEX.ZIP
        PD1:<MSDOS.PGMUTL>DOSRCSMP.ZIP
        PD1:<MSDOS.PGMUTL>MKSRCSEX.ZIP

On star.cs.vu.nl in pub/cvs is a  shell script version of the CVS
front end for RCS by Dick Grune, Vrije Universiteit, de Boelelaan
1081, 1081 HV Amsterdam, the Netherlands, dick@cs.vu.nl.

On  uunet.uu.net  in ~ftp/comp.sources.unix/volume22/cvs-berliner
is a C version of  CVS front end for RCS by Brian Berliner, Rocky
Mountain Technology Center, Sun  Microsystems, 5465 Mark  Dabling
Blvd., Colorado Springs, CO 80918, berliner@sun.com.

RCS and  CVS may  also be   found on prep.ai.mit.edu although the
locations referred to above may have more recent versions.

A number of SCCS front ends have been posted to comp.sources.unix
and alt.sources.


REFERENCES

 Marc J. Rochkind, "The Source Code Control System",
 IEEE Transactions on Software Engineering, Vol SE-1(4), 364-370, Dec 1975.

 Walter F. Tichy, "RCS -- A System for Version Control",
 Software--Practice and Experience, Vol 15(7), 637-654, Jul 1985.


THANKS

Thanks to the following for posting or sending me emails:

bad@atrain.sw.stratus.com (Bruce Dumes)
berliner@rmtc.Central.Sun.COM (Brian Berliner)
bhahn@bogus.sw.stratus.com (Bill Hahn)
cbmvax!hutch!purdom@uunet.UU.NET (purdom)
celit!billd@celerity.fps.com (Bill Davidson)
charles@phx.mcd.mot.com (Charles Wolff)
dick@cs.vu.nl (Dick Grune)
drz@csri.toronto.edu (Jerry Zarycky)
emv@math.lsa.umich.edu (Edward Vielmetti)
guy@auspex.auspex.com (Guy Harris)
jmm@eci386.uucp (John Macdonald)
johnl@iecc.cambridge.ma.us (John R. Levine)
leadsv!white@apple.com (Ben White)
mks!watmath!domain.com!mdv (Mike Verstegen)
rick@tetrauk.tetrauk (Rick Jones)
rob@b15.INGR.COM (Rob Lemley)
sdrc!scjones%thor@uunet.UU.NET (Larry Jones)
watmath!acf4.NYU.EDU!poppers (Michael Poppers)
watmath!servio.SLC.COM!penneyj (D. Jason Penney)
woods@eci386.uucp (Greg A. Woods)

rickert@mp.cs.niu.edu (Neil Rickert) (11/09/90)

In article <2252@megadon.UUCP> louk@tslwat.UUCP (Lou Kates) writes:
>The following describes the relative advantages and disadvantages
>of SCCS vs. RCS. The * indicates which of the two on each line is
>(...)
>
>Item            SCCS                          RCS
>
>make            understands SCCS*             does not understand RCS

  This may be version dependent.  The 'make' I am using understands RCS.
I am not sure whether it understands SCCS.  (On Umax 4.3, 'make' is as
supplied by the vendor, Encore).

-- 
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  Neil W. Rickert, Computer Science               <rickert@cs.niu.edu>
  Northern Illinois Univ.
  DeKalb, IL 60115.                                  +1-815-753-6940

heiney@wsl.dec.com (Bob Heiney) (11/09/90)

The Free Software Foundation's make program includes
support for RCS, so you can have automatic check out
if you want to.

Bob

bruce@balilly.UUCP (Bruce Lilly) (11/15/90)

>The Free Software Foundation's make program includes
>support for RCS, so you can have automatic check out
>if you want to.

Last time I looked, GNU make didn't support SCCS however.  Specifically,
GNU make doesn't handle the ~-hack in the SUFFIX rules for identifying
SCCS files.  If one has many makefiles which are designed to handle SCCS
files, there is strong incentive to not use GNU make.

On the other hand, if one uses a ``standard'' make, there is no support
for a ',' as a delimiter for suffixes, so it's rather difficult to
automate use of RCS.

The result: migration from one system to the other, or use of both SCCS
and RCS can be difficult.

--
	Bruce Lilly		blilly!balilly!bruce@sonyd1.Broadcast.Sony.COM

guy@auspex.auspex.com (Guy Harris) (11/15/90)

>make            understands SCCS*             does not understand RCS

There do exist versions of "make" that understand RCS, although
the vanilla S5 one doesn't have built-in RCS support the way it has
built-in SCCS support, and I don't think it's easy to add in without
source.  The SunOS 4.x "make" doesn't have built-in RCS support the way
it has built-in SCCS support, either, but you can add rules to help.

There also exist versions of "make" that don't understand SCCS....

>speed           retrieve old versions faster  retrieve latest version faster

WRONG.  Older versions are NOT faster in SCCS.  Didn't I say that in my
message?

cudcv@cu.warwick.ac.uk (Rob McMahon) (11/21/90)

>On the other hand, if one uses a ``standard'' make, there is no support for a
>',' as a delimiter for suffixes, so it's rather difficult to automate use of
>RCS.

Uh ?  You don't need it.  Most of what you need can be done with rules like

.SUFFIXES:	.c,v

.c,v.c:
	$(CO) -q $*.c
.c,v.o:
	$(CO) -q $*.c
	$(CC) $(CFLAGS) -c $*.c
	$(RM) -f $*.c

... etc.  Note that for SCCS it *has* to be built into make, because it uses
prefixes instead of suffixes.

Rob
--
UUCP:   ...!mcsun!ukc!warwick!cudcv	PHONE:  +44 203 523037
JANET:  cudcv@uk.ac.warwick             INET:   cudcv@warwick.ac.uk
Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England

donn@hpfcdc.fc.hp.com (Donn Terry) (11/21/90)

Item            SCCS                          RCS

speed           retrieve old versions faster  retrieve latest version faster

This isn't quite true:

SCCS:	Linear in the size of the SCCS file for any revision.
        (Retrieve any version in the same amount of time.)

RCS:    O(n), where n is the number of changes between the top and the
	requested version.  (Retrieve old versions very slowly.)

In practice, top revision is slightly faster (for the same history)
for RCS, but small enough in either case as to not really matter (a
few seconds at most; not enough time to think about the difference).

Donn Terry
HP, Ft. Collins.

balilly@Broadcast.Sony.COM (Bruce Lilly) (11/28/90)

>>On the other hand, if one uses a ``standard'' make, there is no support for a
>>',' as a delimiter for suffixes, so it's rather difficult to automate use of
>>RCS.
>
>Uh ?  You don't need it.  Most of what you need can be done with rules like
>
>.SUFFIXES:	.c,v
>
>.c,v.c:
>	$(CO) -q $*.c
>[ ... ]
>... etc.  Note that for SCCS it *has* to be built into make, because it uses
>prefixes instead of suffixes.

The premise of Rob's ``solution'' is that *all* files have a '.'
somewhere.  This doesn't work, e.g., for s.Makefile -> Makefile. For that
to work, a ',' would have to operate as a SUFFIX delimiter, which it does
not do in ``standard'' make. There's no way to make make make Makefile
from Makefile,v using ony SUFFIX-based rules. An explicit dependency line
and rule would be required for each and every file.

P.S. Note that make will automatically do a get if there is an s.Makefile
(or s.makefile) and neither Makefile nor makefile exist.  In short, make and
SCCS are well integrated.
--
	Bruce Lilly		blilly!balilly!bruce@sonyd1.Broadcast.Sony.COM

eggert@twinsun.UUCP (Paul Eggert) (12/07/90)

    There's no way to make Makefile from Makefile,v using only SUFFIX-based
    rules. An explicit dependency line and rule would be required for each
    and every [such] file.

Not true.  Here's how to do it:

	.SUFFIXES : ,v

	,v :
		co -q $*


Lilly also writes:

    make will automatically do a get if there is an s.Makefile (or s.makefile)
    and neither Makefile nor makefile exist.  In short, make and SCCS are well
    integrated.

make and RCS are similarly well integrated, if you have a modern version of
make, e.g. GNU make 3.58.  For older makes, you can use the trick described
above.

woods@eci386.UUCP (Greg A. Woods) (12/07/90)

In article <2282@megadon.UUCP> balilly@Broadcast.Sony.COM (Bruce Lilly) writes:
>[....]
> The premise of Rob's ``solution'' is that *all* files have a '.'
> somewhere.  This doesn't work, e.g., for s.Makefile -> Makefile. For that
> to work, a ',' would have to operate as a SUFFIX delimiter, which it does
> not do in ``standard'' make. There's no way to make make make Makefile
> from Makefile,v using ony SUFFIX-based rules. An explicit dependency line
> and rule would be required for each and every file.

[ I *really* like your use of the English language! ;-) ]

You can always use something like the .sh rule by calling your file
"Makefile.sh".  Non-traditional, and potentially confusing, but it
works.

> P.S. Note that make will automatically do a get if there is an s.Makefile
> (or s.makefile) and neither Makefile nor makefile exist.  In short, make and
> SCCS are well integrated.

Unfortunately I find make a little lacking when it comes to either RCS
or SCCS.  Gnumake is slightly better, and perhaps dmake is too, but
they are non-standard, and versions I've tried were either buggy, or
not compatible with SysV make.  SysV make won't find SCCS/s.[Mm]akefile,
for example.

Instead, I prefer to "keep it simple, stupid", and not deal with the
version control through make.  I use RCS or SCCS with "sccs" in a mode
where they are transparent, and make need know nothing about them.
All files are always "checked out" and visible to make.  The very
nature of the way one uses "sccs", for example, ensures this is always
true.
-- 
							Greg A. Woods
woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP		ECI and UniForum Canada
+1-416-443-1734 [h]  +1-416-595-5425 [w]    VE3TCP	Toronto, Ontario CANADA
"Political speech and writing are largely the defense of the indefensible"-ORWELL

jfh@rpp386.cactus.org (John F Haugh II) (12/27/90)

>make and RCS are similarly well integrated, if you have a modern version of
>make, e.g. GNU make 3.58.  For older makes, you can use the trick described
>above.

Except for the initial checkout of Makefile.  I have two versions of a
collection of software I manage in SCCS right now.  The version is
selected by a flag contained in the Makefile.  If there is no currently
checked out version, it gets the latest one.  "Standard" make won't do
this if RCS is used.  I'd love to run GNU software, but I just don't
have the disk space to spare ;-)
-- 
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832                           Domain: jfh@rpp386.cactus.org