Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!ncar!umigw!steve
From: steve@umigw.MIAMI.EDU (steve emmerson)
Newsgroups: comp.software-eng
Subject: Re: Source Code Control
Message-ID: <370@umigw.MIAMI.EDU>
Date: 28 Jun 89 14:36:58 GMT
Reply-To: steve@umigw.miami.edu (steve emmerson)
Organization: Rosenstiel School of Marine and Atmospheric Science
Lines: 23

In article <412@coma.UUCP> andy@coma.UUCP (Andreas Lampen) wrote about
SHAPE(1).  This caused me to wonder how it could handle a real-world
software configuration problem example which was recently posted: namely, 
correcting a bug in an already-released module which has already been 
subsequently modified.

The situation is this: version 2.0 of "foo.c" has been released with version 
1.0 of The Product.  It has since been modified and is currently at version
3.1 of version 1.7 of The Product.  A bug report on the 2.0 "foo.c" comes in.  
What to do?

The originator of this example (sorry, I've forgotten the name) solved the
problem by creating a (soon to be a dead-end) branch off of the 2.0 version
of "foo.c" and shipping that off to the user.  Shape(1), on the other hand, 
disallows branches.  I assume other configuration/revision management systems 
also disallow branching.

How, then, can this situation be handled by such non-branching systems?
-- 
Steve Emmerson                     Inet: steve@umigw.miami.edu [128.116.10.1]
SPAN: miami::emmerson (host 3074::)      emmerson%miami.span@star.stanford.edu
UUCP: ...!ncar!umigw!steve               emmerson%miami.span@vlsi.jpl.nasa.gov
"Computers are like God in the Old Testament: lots of rules and no mercy"