Usage of sccs - a summary of replies

[Ian Phillipps]

A few weeks ago I posted a request for 'sccs' users to tell me of hints or
problems. Here is a short summary of the responses; more info on request.

>From Marc Evans <marc at ima.isc.com>
... BSD sccs assumed...
	- Create a directory structure in which the SCCS sources will be
	  placed. All of these directories should be owned by sccs, group
	  set to sccs, and mode 750 or 755.
	- Create a second directory structure which is a mirror image of the
	  first, but this time the owners, and groups can be almost anything.
	  If you want anybody to be able to use any of the directories, set
	  the mode to 777. In each of these directories, create the standard
	  SCCS symbolic link to the corresponding directory in the first
	  directory structure.
	- Have each programmer copy (not move) their code into the proper
	  directory in the second directory structure. You should then 
	  create the SCCS version of each before they do any more work
	  (sccs create -r1 [other admin flags] source files). Also, archive
	  onto tape the orignal sources from their original directories, and
	  then delete them.
	- Chances are, each programmer has created makefiles in their own
	  manner. You will probably want to create all of the makefiles
	  yourself, following some standard. At the end of this message, I
	  will enclose a makefile generator and dependancy list generator
	  that I use here. This can make your job alot easier.
[Sun's 'cc' will generate dependancy lists from c sources]
	- When creating the makefiles, remember that you need 2 things to
	  happen; they should traverse directories, and also make targets.

I also had a reply from Robert Hartman <rdh at sun.uucp>, who is in charge of
the Sun 'make' and 'sccs' files, who also mentioned symbolic linking. (It also
made sure I read the make and sccs manuals more thoroughly :) He also dealt
with techniques like
	/usr/src/lib/foo/libfoo.a: FORCE
		cd $(@D) ; make $(@F)
	FORCE:
	# null rule

to perform nested makes.

Andy Greener <andy at ist.co.uk> writes:

Administer everything, even README files. It makes things easier in the
long run, even if it sounds like overkill.

The major problem with SCCS is the lack of any sort of "symbolic"
tagging of versions. ... However it can be dealt with. We have
built some tools for automatically constructing releases from ...
snapshot files.

Avoid SCCS branching. It sucks (basically!).

Use SCCS id keywords in sources so they appear in the binaries...
We use: "%Z%%Q%%M%      %I%" , where %Q% is set to the path segment from
the root of the source tree to the current dir.

Beware of administering non-printable files (e.g. icons).

Charles Lambert <cl at datlog.co.uk>:

... Keep a System Description File that
lists all the version-numbered sources needed for a correct build.  This
is simply a text document that has to be kept up to date.  Since nobody
remembers to keep documents up to date,  it is wise to have your shell
scripts do it automatically:  every time someone deltas a file, the new
version number gets written into the SDF.

John Dempsey <john at cam.unisys.com>

At home, I have a Unix PC ...
I really don't see any pitfalls to using SCCS.

     However, RCS is the better source code control system, because 
it will instantly give you the most recent version of a source file. ...
I think SCCS is pretty straight forward.

Thanks to everyone who replied.


-- 
UUCP:  ...!ukc!camcon!igp | Cambridge Consultants Ltd  |  Ian Phillipps
or:    igp at camcon.uucp    | Science Park, Milton Road  |-----------------
Phone: +44 223 358855     | Cambridge CB4 4DW, England |