Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!linus!philabs!ttidca!hollombe
From: hollombe@ttidca.TTI.COM (The Polymath)
Newsgroups: comp.software-eng
Subject: Re: Coordinating Software Development (long)
Keywords: configuration management, sccs, project control
Message-ID: <1818@ttidca.TTI.COM>
Date: 1 Feb 88 23:08:43 GMT
References: <368@dlhpedg.co.uk> <2457@orca.TEK.COM> <1713@ttidca.TTI.COM> <1315@vaxb.calgary.UUCP>
Reply-To: hollombe@ttidcb.tti.com (The Polymath)
Organization: The Cat Factory
Lines: 26

In article <1315@vaxb.calgary.UUCP> jonesb@calgary.UUCP (Bill Jones) writes:
=Okay, suppose your company is working on the next release of a product
=already in the field.  An important customer reports a critical bug,
=and you find that the fix for it involves several modules which are
=checked out and being modified for the next release.  Should that team
=be held up while you yank back the modules and figure out how to
=recompose the customer's configuration?  Or do you mean to tell the
=customer that his bug can't be fixed until the next release is out?

Neither.  You ship the customer(s) a temporary patch for the existing
code.  Patched versions of code don't get checked in (but the patches do,
for the record).  Then you include the fix in the next release (based on
the patch).  This causes minimal disruption to the work on the next
release.

If you're working in a high-level language you probably aren't going to
literally patch the code, but the process can logically be treated in the
same way.  The people working on the release still have only one version
of each module to work with, and the patch becomes an addition to their
task list.

-- 
The Polymath (aka: Jerry Hollombe, hollombe@TTI.COM)   Illegitimati Nil
Citicorp(+)TTI                                           Carborundum
3100 Ocean Park Blvd.   (213) 452-9191, x2483
Santa Monica, CA  90405 {csun|philabs|psivax|trwrb}!ttidca!hollombe