naked SCCS really SCCS!

[Ed Mackenty]

In article <167 at cat.Fulcrum.BT.CO.UK> tjo at fulcrum.bt.co.uk (Tim Oldham) writes:
>In article <8218 at june.cs.washington.edu> ka at june.cs.washington.edu (Kenneth Almquist) writes:
>>OK, let's say you want to keep all your "s." and "p." files in a
>>subdirectory named sccs.  Say
>>	mkdir sccs		# create the directory
>>	admin -n sccs/s.file.c	# create an SCCS file
>>	...
>
>Yuck. I prefer the idea of SCCS doing this stuff for you.  ...

I agree, the SCCS interface should hide as much as it can from the user.
My model of a code control system is one in which the user knows nothing
about how the system works.  They use a few commands with almost no options,
and always refer to g-file names (i.e., their own name for the file, not
SCCS's name).  At this site, we implemented a layer on top of SCCS that
does this (and more).  It also addresses the problems of many users working
on the same set of sources without interfering with each other.  While it
works well for us, I would not wish it on anyone else.  It has evolved over
a period of years, depends heavily on our local environment, and seems to
require at least one guru to administer it and help users understand it.
Maybe if we wrote some documentation... :-).

I haven't been following this discussion for very long (I just fixed our
new link, again), but I'd like to change the direction of this duscussion
from SCCS bashing (which is in itself a worthwhile pursuit) to the subject
of source code control in general.  I've talked to several local programmers
from other companies to get ideas to put into our system and they all say
the same thing: "Code control?  Well, we have these diskettes with today's
version of the product on them..."  Does anyone out there uses a system
like SCCS or RCS in a product development effort?  What sorts of problems
have you run into?  What solutions do you have?  I could write several pages
about what we've encountered here, but this message is too long already.
If there is any interest, I'll write another message.
	- MacK (developing programs for program development).
-- 
- MacK		Edmund R. MacKenty
UUCP:		...{uunet,rutgers,ames}!harvard!talcott!kurz-ai!mack
DISCLAIMER:	But... I was off planet that week!
DEAD QUOTE:	"And the politicians Throwing Stones."