Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!zephyr.ens.tek.com!tektronix!nosun!fpssun!celit!billd
From: billd@fps.com (Bill Davidson)
Newsgroups: comp.sources.d
Subject: Re: rcs for SysV
Message-ID: <1618@celit.fps.com>
Date: 12 Oct 89 03:02:11 GMT
References: <78@vidiot.UUCP> <1367@celit.fps.com> <6218@pbhyf.PacBell.COM>
Sender: daemon@fps.com
Reply-To: billd@fps.com (Bill Davidson)
Distribution: na
Organization: FPS Computing Inc., San Diego CA
Lines: 58

In article <6218@pbhyf.PacBell.COM> rob@PacBell.COM (Rob Bernardo) writes:
>In article <1367@celit.fps.com> billd@fps.com (Bill Davidson) writes:
>+Does anyone know why Berkeley (or anyone in their right mind) still uses SCCS?
>
>Because make (at least the augmented version  of make) understands SCCS.

The make on my System V machine does know about SCCS but only if the SCCS
file is in the current directory.  I keep mine in sub-directories so it
doesn't do me much good.  I really hate keeping everything in one directory.
The ,v is already handled by the .SUFFIXES on any make since all you need
are rules like:

	.c,v.c:
		$(CO) $(COFLAGS) $<

and have ".c,v" be after ".c" in your ".SUFFIXES" line.  So any make
understands RCS as well as my System V make understands SCCS.  True, you
have to make your own ".SUFFIXES" and a few new implicit rules but it's
better than naming every bleeding dependancy.  I have heard some good
reasons but IMHO this isn't one of them.  

The make I have on my Berkeley systems is also modified so that it accepts
a ".PREFIXES" target, much in the same manner as ".SUFFIXES".  We typically
put a line like:

	.PREFIXES	./RCS/

in our makefiles.  I haven't tried a "s." in the prefixes line yet but
I suspect it would work.  I don't use SCCS where I don't have to.  I wish
I could get this in my System V make.  I believe VPATH is supposed to
be the same thing but it doesn't work in the System V make that I have.
In any case, since I do use subdirectories, I'm cursed with explicit
dependancies.

For those of you who are curious, here are the reasons that I think are
valid that I've heard so far:

	1. One person said that they had a vast amount of code and that
	conversion would be a monumental task.  I'm going through this
	myself with several megabytes of code right now.  I can see why
	one would be afraid to do it.  sccstorcs is slow (actually it's
	slow because it uses get and ci to do most of the work and they
	are slow).  Also, you have to change all your makefiles.  This
	is a definite deterent to conversion :-).

	2. Another person had a lot of code which had many branches and
	he used a lot of old revisions.  When you do a lot of this kind of
	thing SCCS is faster than RCS.  RCS is only faster when you are
	grabbing the latest revision.  I grab the latest revision about 95%
	of the time so this means nothing for me but I can see how it could
	matter to others.

	3.  SCCS allows you to lock more than one revision of a file at
	a time.  This is from the same person mentioned in reason #2.
	If you deal with a lot of branches, I can see this.  I don't so
	I don't care.

--Bill Davidson