naked SCCS really SCCS!

Ed Mackenty mack at kurz-ai.UUCP
Wed May 31 00:15:30 AEST 1989


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
news link, again), but I'd like to create a branch of this discussion on 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 use
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:	kurz-ai!mack at talcott.harvard.edu
	or:	...{uunet,rutgers,ames}!harvard!talcott!kurz-ai!mack
DISCLAIMER:	But... I was off planet that week!
DEAD QUOTE:	"And the politicians Throwing Stones."



More information about the Comp.unix.questions mailing list