Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!bloom-beacon!think!redsox!campbell
From: campbell@redsox.bsw.com (Larry Campbell)
Newsgroups: comp.software-eng
Subject: Re: Source Code Control
Message-ID: <793@redsox.bsw.com>
Date: 26 Jun 89 01:21:30 GMT
References: <791@redsox.bsw.com> <357@umigw.MIAMI.EDU>
Reply-To: campbell@redsox.UUCP (Larry Campbell)
Organization: The Boston Software Works, Inc.
Lines: 57

In article <357@umigw.MIAMI.EDU> steve@umigw.miami.edu (steve emmerson) writes:
-In article <791@redsox.bsw.com>, Larry Campbell <campbell@redsox.UUCP> 
-describes a possible methodology for configuration management using the
-"state" attribute of individual RCS files.  In the description, an
-example is given in which a bug-fixed module is "back-dated" into an 
-already released version.
-
-IMHO, this should be done with extreme caution --- if at all.  If one
-updates a module, but still associates it with a previous version of the
-total package, then one has effectively by-passed the primary purpose
-of a configuration management system: namely, to unambiguously bind a
-release to a set of modules.

Not at all -- there is no ambiguity, as long as we've not yet released
-- i.e., shipped -- the bits.  You're right, though, if we had actually
shipped bits, we'd have to bite the bullet and create a new version.

For example -- let's say it's the final release of a product, but someone
forgot to take the "Warning -- BETA test version" message off the main menu.
We freeze the configuration (creating an appropriate state), do a build,
run the QA test suite, everything checks out OK, we build a tape and then
someone notices the botch.  So now we just check out the offending module,
make the edit, back the module into the release, and re-build the release.
As long as we haven't shipped the tape, I see no harm here.

-It would be better, IMHO, to increment the release level (i.e. "state")
-of all other modules --- regardless of the difficulty of doing so.

I disagree.  Chances are that other modules have already had edits that
you DON'T want going in to the release -- i.e., edits for the next major
development version.

There is one problem with the scheme I suggested, though, which I noticed
only after I posted the original article.  Unfortunately, a revision can
have only one state.

This is a problem because we believe strongly in code reuse.  We have
several modules that are used by more than one product.  Ideally, we'd
like to be able to say something like:

	This is rev 2.4 of foo.c, and it belongs to:
		Product A version 1.05
		Product B version 2.06
		Product C version 1.34

I can't think of any good way (short of building an add-on wart) to do
this in either RCS or SCCS.

DEC's source code control system, CMS, allows you to assign revisions
(they call them generations) to one or more "classes".  In the example
above, I'd have classes called, say, "Product_A_V1.05", "Product_B_V2.06",
and "Product_C_V1.34", and rev 2.4 of foo.c would belong to all three
classes.
-- 
Larry Campbell                          The Boston Software Works, Inc.
campbell@bsw.com                        120 Fulton Street
wjh12!redsox!campbell                   Boston, MA 02146