Xref: utzoo comp.unix.questions:13584 comp.sources.wanted:7378
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!uw-june!ka
From: ka@june.cs.washington.edu (Kenneth Almquist)
Newsgroups: comp.unix.questions,comp.sources.wanted
Subject: Re: naked SCCS really SCCS!
Summary: How to use SCCS
Keywords: SCCS, SystemV, obnoxious_program
Message-ID: <8218@june.cs.washington.edu>
Date: 14 May 89 12:42:52 GMT
References: <297@tree.UUCP> <123@tdl.UUCP> <354@greek.UUCP> <160@cat.Fulcrum.BT.CO.UK>
Organization: U of Washington, Computer Science, Seattle
Lines: 62

tjo@Fulcrum.BT.CO.UK (Tim Oldham) writes:
> But the trouble with sysV sccs is the brain-damaged way it
> keeps all the s- and p-files in the directory you're working in. Crazy!

It keeps them where ever you put them.

> If anyone can tell me how to get sccs to use an SCCS directory, I'd
> be *extremely* grateful.

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
	get -e sccs/s.file.c	# get the file for editing
	emacs file.c		# edit the file
	delta sccs/s.file.c	# install changes

The s-file is in the sccs directory because in the UNIX file naming
scheme, a name like "dir/file" means that the file "file" is in the
directory "dir".  The p-file is in the sccs directory because SCCS
commands place the p-file in the same directory as the s-file.  The
g-file (file.c) is placed in the current directory because SCCS
commands always place the g-file in the current directory.

> And what's happened to fix? Wow, so I can cdc
> to change the delta commentary, but that's not a great deal of help.
> I always feel guilty using chmod, vi and admin -z around s-files,
> and quite right too.

You aren't supposed to make mistakes. :-)  Seriously, SCCS is intended
to keep a record of all the changes to a file.  You aren't supposed
to mess with this history.  There are a few exceptions to this.  You
can remove the last delta created (with rmdel) if there is a mistake
in it.  This doesn't violate the SCCS philosophy because you can get
the same effect by simply being less hasty in running "delta".
(Personally, though, I wouldn't bother with rmdel.  Just create a new
delta on top of the old one.)  The admin command allows you to change
various attributes of SCCS files.  Finally, if you want to save disk
space you can use "comb" to really old versions which you are sure you
will never want to return to.  This violates the SCCS philosophy, and
is a concession to the reality that disk space is not infinite.  (My
own view is that the price of disk space is likely to fall faster
than your SCCS files grow, so I wouldn't bother with "comb".)  The
only things that I can think of that SCCS does not allow you to do
without editing the SCCS files by hand are:

    1)	Changing the text of deltas.  As I explained above, since
	the whole purpose of SCCS is to keep an unchanged record,
	you don't want to do this (except possibly for the most
	recent delta, and even then you can simply create another
	delta).

    2)	Change the release numbers.  This *is* a valid reason for
	editing the SCCS files if you need to do it, but in general
	you can avoid the need for renumbering.

In short, the four commands admin, get, delta, and prs (*without*
the -z option to admin) let you do just about anything you need to.
If you want to do something that these commands won't let you do,
perhaps you should think a little more about what you are trying
to accomplish.
				Kenneth Almquist