Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!att!pegasus!psrc
From: psrc@pegasus.ATT.COM (Paul S. R. Chisholm)
Newsgroups: comp.software-eng
Subject: Re: Source Code Control
Summary: slists
Message-ID: <597@pegasus.ATT.COM>
Date: 23 Jun 89 04:26:41 GMT
Organization: AT&T Bell Laboratories
Lines: 52

One of the questions raised in this discussion (in an article I lost)
is about keeping track of versions of the *product*, not just versions
of the source files.  (Like other members of this discussion, I think
that "source files" includes specifications, design documents, test
plans and scripts, end user manuals, etc.)

One useful method of doing this is to use "slists".  An slist is a list
of which versions of which source files you're using at any given time.
(In the SCCS world, it's a "what" of the sources*, plus some header
information with percent strings in it.)  An slist is generated
mechanically from the source files, and itself kept under source code
control.

(*Originally, an slist was a "what" of the product.  This lead to an
odd chicken-and-egg problem:  the slist is a "what" of the product, but
the product has to have the slist version ID in it!  We had a kludgey
two step manufacturing process for this.  Checking the consistency of
the version IDs in a product is still a good idea.)

Slists are used to get a snapshot of the product from the source code
database.  If I want to look at the currently distributed version of a
certain product, I don't have to look for dates; I "get" ma.sl at the
appropriate version (2.103.1.3 or some such), and then "get" the
appropriate source files at the versions listed in the slist.  If I
want to turn it over to system test for manufacturing, I just tell them
the slist name and number; they get the slist, the makefile and other
source files at the appropriate versions, and build.

"Branch deltas" (supporting a tree of different changes) are a handy
feature; read the get(1) and delta(1) manual pages for details.  In
practice, we find that they work very nicely.  Another approach is to
support a number of parallel "generics".  For example, I might have a
2.0 generic (which includes bug fix releases such as 2.01 and 2.02), and
a 2.1 generic (which will include a whole host of new features, when it
eventually is released).  Each change is applied to the appropriate
generics.  (Adding a new way of editing would only be added to the 2.1
generic, but every generic would get a bug fix that prevented a core
dump.)

By the way, for any of you building products on a UNIX(R) System V
(release 3 only?) platform, I strongly recommend using the mcs command
to get rid of redundant SCCS IDs.  Your code might not have these, but
the files in /usr/include have lots of long ones.  I trimmed 100Kbytes
of ugly fat off of one program with this, and shrunk another by forty
percent!

Paul S. R. Chisholm, AT&T Bell Laboratories
att!pegasus!psrc, psrc@pegasus.att.com, AT&T Mail !psrchisholm
I'm not speaking for the company, I'm just speaking my mind.
UNIX(R) is a registered trademark of AT&T.  So far as I know, outside
of SCCS utilities that form a foundation for internal tools, we don't
sell tools that support slists.