igp@camcon.uucp (Ian Phillipps) (04/29/88)
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@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@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@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@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@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@camcon.uucp | Science Park, Milton Road |-----------------
Phone: +44 223 358855 | Cambridge CB4 4DW, England |