Xref: utzoo comp.software-eng:505 comp.unix.wizards:8168 Path: utzoo!mnetor!uunet!mcvax!ukc!stl!stc!idec!camcon!igp From: igp@camcon.uucp (Ian Phillipps) Newsgroups: comp.software-eng,comp.unix.wizards Subject: Usage of sccs - a summary of replies Message-ID: <1431@titan.camcon.uucp> Date: 29 Apr 88 11:22:58 GMT Organization: Cambridge Consultants Ltd., Cambridge, UK Lines: 84 Keywords: sccs control project 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 ... 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 , 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 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 : ... 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 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@camcon.uucp | Science Park, Milton Road |----------------- Phone: +44 223 358855 | Cambridge CB4 4DW, England |