Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!asuvax!ncar!hsdndev!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.unix.questions
Subject: Re: RCS info wanted
Message-ID: <15484@smoke.brl.mil>
Date: 15 Mar 91 20:21:32 GMT
References: <AMIR.91Mar14144117@pilat.Israel.Silvaco.COM> <1991Mar15.175701.17723@athena.mit.edu>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 27

In article <1991Mar15.175701.17723@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes:
>  One of the biggest differences between the two (in my opinion) is that the
>basic SCCS commands are very primitive and almost impossible for the user to
>"just use" -- you almost certainly need some sort of front-end in order to use
>SCCS effectively.

I disagree -- the BRL MUVES project (over 100,000 lines of code in numerous
files in dozens of directories, with a half dozen developers) uses SCCS to
maintain the source code, documentation, etc. and it is pretty easy to use
for routine purposes:
	admin -ifoo s.foo	# to create the initial archive
	get s.foo		# to check out the latest version
	get -e s.foo		# to check out for editing
	delta s.foo		# to check back in after editing

The main need for any sort of "front end" program occurs on Berkeley-based
systems where it is desired to strictly enforce access controls, due to
lack of kernel support for the sort of UID manipulation that SCCS relies
upon to support such usage.  However, if you simply rely on the normal
user/group permissions, as we do for the MUVES project use of SCCS, it
works adequately.

It also helps if you have an "augmented make" that knows how to deal with
the s. prefixes, and if your Makefiles for documentation etc. contain

.DEFAULT:
	$(GET) $(GFLAGS) -p s.$@ > $@