Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!uwvax!tank!uxc!uxc.cso.uiuc.edu!gistdev!joe
From: joe@gistdev.UUCP
Newsgroups: comp.software-eng
Subject: Re: Source Code Control
Message-ID: <8100004@gistdev>
Date: 13 Jun 89 14:06:00 GMT
References: <133@tirnan.UUCP>
Lines: 51
Nf-ID: #R:tirnan.UUCP:133:gistdev:8100004:000:3102
Nf-From: gistdev.UUCP!joe    Jun 13 09:06:00 1989


> Written 11:36 am  Jun 10, 1989 by tirnan.UUCP!john in comp.software-eng
>     [...]       I've worked with several (mostly ad-hoc) variants of
>     development based on either SCCS or RCS and find that the structure
>     is generally not in place to provide a development model that
>     allows for realistic development of a Product and any variants and
>     descendents of it (admittedly this often results from lack of
>     organizational focus on the problems). I believe that this is due
>     to an inherent weakness in the model of a product as the state of a
>     particular set of source files, rather than as the collection of
>     source files and configuration specifics that define a particular
>     instance of the product.

I think that this is true in several regards.  When we set up our source code
control system (we use SCCS, and yes, we looked at RCS), we found (like
everyone else), that controlling source files is not enough.  You need the
ability to track the state of a "program" (I'll define that in just a moment)
including not just source code, by documentation, make files, testing files,
and any other associated text.

Our model of what a "program" is varies depending on the nature of the
software.  A program is usually a traditional set of source code that compiles
to make a binary.  However, a program could be a set of text files, a simple
UNIX shell script, a source code library, a binary library -- anything that
can be tracked back to a set of controlled text files and can be given a
collective version number.

Our SCCS implementation includes a set of UNIX shell utilities which track
versions of each "program", and the scripts do the house-keeping as to which
versions of which files comprise the program.  For our products, then, we
maintain an even higher level set of scripts which track which programs 
(remember, a program could even be a simple set of text files) made up each
version of the product.  In this way, from a single product version number,
we can easily back-track to each version of each file that comprised that
product.

We have found that this model has worked for us, even in situations where
parallel copies are under development, or patches must be made to older
releases.  But I think the key is that just tracking source files is not
enough, because that's just too low a level to reasonably track.  It is
better to control things at the program level, and let the computer deal
with the details of individual files for you.  Then you can concentrate on
the organization issues mentioned above.

-------------------------------------------------------------------------------
Joe Brownlee       | The best diplomat I know is a fully activated phaser bank.
GIST, Inc.         |                                -- Montgomery Scott
1800 Woodfield Dr. | Pay attention to what I say, and you might start a trend.
Savoy, IL 61874	   | ARPANET: joe%gistdev@uxc.cso.uiuc.edu
(217) 352-1165	   | UUCP   : {uunet,pur-ee,convex}!uiucuxc!gistdev!joe
-------------------------------------------------------------------------------