Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!motcsd!hpda!hpcupt1!hpirs!runyan
From: runyan@hpirs.HP.COM (Mark Runyan)
Newsgroups: comp.software-eng
Subject: Re: Re: Source Code Control
Message-ID: <9630004@hpirs.HP.COM>
Date: 25 Jun 89 22:12:59 GMT
References: <133@tirnan.UUCP>
Organization: HP GSY/USO/UKL Cupertino, CA, USA
Lines: 27

>/ psrc@pegasus.ATT.COM (Paul S. R. Chisholm) /  9:26 pm  Jun 22, 1989 /
>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.  ...
>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.

While the term "slist" is new to me, the concept isn't, and I agree that
this appears to be a good way to track what versions go into a product.
(I've encountered this concept in "The DOMAIN Software Engineering
Environment for Lage Scale Software Development Efforts" by David Leblang,
Robert Chase, and Gordon McLean as printed in the May 1985 issue of IEEE.
The term "thread" was used and is part of Apollo's DSEE product).

Some care must be taken, though, by those who are working on complex
projects.  In one project I worked on at another company, the project
kept the list of versions (which I'll call an slist for now).  The
project was fairly complex with several parts.  The management team
discovered that version A of their product worked (more or less), but
version B had a bug, so they wanted to experiment with the slists to
make a version A/B to combine the best of both worlds.  They didn't
quite have a feel for the dependancies of the files, and their modified
slist checked out "garbage" that wouldn't compile.   The lesson I
learned from that was:  An slist is a good history tool, but not an
efficient development tool.

Mark Runyan