SCCS REVISION HISTORY

[Greg A. Woods]

In article <1762 at b15.INGR.COM> rob at b15.INGR.COM (Rob Lemley) writes:
> In <1990Oct25.163501.16809 at eci386.uucp> woods at eci386.uucp (Greg A. Woods) writes:
> >Have you tried sccs (i.e. Eric Allman's front-end)?  It makes using
> >SCCS a breeze.  There are even a few other front ends....
> 
> Can anyone elaborate on these front ends?  Availability, functionality, etc?

I use Eric Allman's front-end sccs.  It provides for hiding all of the
s. and p. files in a subdirectory, usually SCCS.  It can be integrated
with make, but I usually keep my Makefiles simple, and pretend that the
SCCS files don't even exist.  Sccs makes this easy, since it's default
is to keep complete copies of everything in the working directory.

Sccs makes creation of the s. files quite easy, and provides a simple
interface to checking in and out by using only the base filename.  You
don't have to have all files in the SCCS databse, so what I commonly
do for local mod's is make everything read-only, and only create s.'s
for what I have to change.  The read-only status makes it easy to
remember to check out something before you modify it.

With a simple set of shell functions or aliases, the SCCS directory
can indeed be somewhere in a central system or project wide location.
(In fact, this could be done with a minor modification to sccs, to
handle environment variables).

I use sccs with a set of aliases (ksh or csh) that make the interface
much like a product called VCS from Polytron.

Sccs can be used as a setuid front-end to SCCS, providing some
protection to source files in a common directory.  Sccs does not
provide access control lists.

Sccs is covered by the Berkeley Software Distribution copyright, and
is essentially freeware.

Also in use at our company is a tool called 's'.  It has the added
advantage of being designed to provide set-uid features that can
provide both protection to the source libraries, as well as providing
default environments for particular libraries.  One example is the
"make" option which invokes make in the directory prefix specified.
and uses the environment (and user-id) of the librarian.  I continue
to use SCCS, since it can do almost everything s can do, with a more
familiar interface.

S is always set-uid, and has something similar to access control
lists, providing per-project specification of user access privileges.

S has full support for Modification Requests, and can insist on every
delta matching a previously supplied MR.

S was developed by one of my colleagues, and I don't know if we can
release it or not.

One problem I've found with using any of these tools (including RCS),
has to do with multi-developer projects.  If you have a common
location for the official sources for a project, owned by the
librarian, you have four options for effectively using these tools.

	1. You have lots of disk space, and everyone keeps a working
	directory up-to-date with a full copy of the project.  This
	option works for small to mid-sized projects, but would be a
	nightmare with something like a complete O/S, etc.

	2. You do everything on a single filesystem and everyone has
	hard links to source files (and maybe objects and libraries)
	in the project directory.  Everyone is very careful about
	not destroying the links.

	3. You have symbolic links, and use them effectively to create
 	a mirror image of the project directory.  This is the most
	flexible option.

	4. You have smart makefiles and build scripts which use the
	versions of sources and objects in the project directory,
	unless a more recent version exists in the current directory,
	and only targets affected by stuff in the current directory
	gets re-built.  This is the option I often choose, since I
	rarely build large projects on systems with symlinks.
-- 
						Greg A. Woods

woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP
+1-416-443-1734 [h]  +1-416-595-5425 [w]    VE3-TCP	Toronto, Ontario CANADA