SCCS: how to handle multiple developers/streams

[Mark Runyan]

>/ tpc at bnr-fos.UUCP (Tom Chmara) / 10:17 am  Nov 24, 1988 /

I'm not an expert in SCCS, so I may not be of any help, but you have
found a problem that everyone using SCCS will encounter eventually...

>1.  Scenario:  Building a new load.  Problem:  devoted developer has a
>    module checked out for editing.  I don't WANT the new version; I want the
>    old one.  "-c" gets the old version, "-G" specifies a new path into
>    which I dump the file.  Ergo, I need a new copy of my source
>    directory structure?  Or does every file need an "alias" for loadbuilding?

I'm not sure I understand the problem the way it is phrased. (I also don't
appear to have the "-G" option you mentioned).  If your developers are
all working in the same directory, the problems you face are very
significant.  SCCS alone may not be the solution.  Perhaps each developer
needs their own workspace (yes, that uses a lot of disk).  With links,
you could reduce the disk space, but managing the links would be
difficult.

>2.  Scenario:  Doing maintenance.  A bug has been reported in existing
>    (read:  non-current) software.  Do I have to rebuild (recompile) the
>    world to be able to restore that environment?  Do I have to maintain
>    a copy of the directory hierarchy for every released version?

Again, separate work spaces are the only answer I see for this.  Once
you have found the fix, checking the fix in on a branch would be a way
to store it.  The environment is a *major* problem.  While SCCS stores
the source for a file, it doesn't keep the environment (i.e.  compilers,
header files, etc) needed to rebuild the exact bits.  I strongly suggest
that a database (which could be something as simple as a flat file and
some awk scripts) be considered for keeping track of which revisions of
which files and programs create a particular environment.  Storing the
old compilers, loaders, etc.  into special directories might be
required.

>2.  Scenario:  Doing development.  Do I need to do development in the
>    current directory (i.e. parent to SCCS directory) and aggravate the
>    loadbuilders (see #1)?  What happens if two of us are doing development
>    in the same directory?  I'd like to use the old (read:  loadbuilt)
>    objects to avoid having to recompile the world; so would s/he.
>    We're constantly going to see each other's sources.  This looks like
>    a problem for the Makefiles...  Unless I actively sccs info each
>    subdirectory, I don't know who else is doing development -- and that
>    information itself is volatile...

If the SCCS directory in *your* working directory is simply a link (symbolic
or otherwise) to the "real" SCCS directory, each work space will use the
same SCCS files but be separate.  This uses a *lot* of disk space when
someone checks everything out.  One solution to this is to have a program
which manages links (i.e. everything is checked out into some location
and linked.  When you want your own copy, break the link.  Need a way to
keep track of which are broken links and which aren't).

>I DO know that both SUN & HP use SCCS at some stage of their development
>efforts, so presumably maintenance of old software streams is a subject
>near (though maybe not dear) to their respective hearts.  Others are also
>likely to be equally knowledgeable.  I'm slowly going nuts trying to envision
>parallel "shadow" directories, (and subdirectories, and...).  Is there
>an easy way out?  Is there a sane way out?  What are my alternatives?

Well... <cough, cough>  I don't think that either SUN or HP uses *just*
SCCS.  (I don't think HP uses SCCS too much, but I could be wrong :-)
SCCS only provides management of the revisions of a file.  Frontends and
support programs must exist to handle work spaces and networking.  Knowing
this will start a "Holy War", I'll mention that RCS allows a person to
manage a group of files, but again, RCS only manages revisions.  The
work space and networking ( and environment ) problems are not solved
by either RCS or SCCS.

If a solution exists, I would really like to hear about it...  I believe
that solutions may arise soon as software configuration becomes more
important, but I'm not aware of any solution available to the customer
at the moment.

Mark Runyan