Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!lll-tis!ames!rutgers!mtune!whuts!homxb!ihnp4!alberta!calgary!jonesb
From: jonesb@calgary.UUCP (Bill Jones)
Newsgroups: comp.software-eng
Subject: Re: Coordinating Software Development (long)
Message-ID: <1315@vaxb.calgary.UUCP>
Date: 26 Jan 88 18:48:35 GMT
References: <368@dlhpedg.co.uk> <2457@orca.TEK.COM> <1713@ttidca.TTI.COM>
Sender: jonesb@calgary.UUCP
Organization: U of Calgary Computer Science, Calgary AB Canada
Lines: 22
Keywords: configuration management, sccs, project control

In article <1713@ttidca.TTI.COM> hollombe@ttidcb.tti.com (The Polymath) writes:
>In article <2457@orca.TEK.COM> stank@orca.UUCP (Stan Kalinowski) writes:
>>In article <368@dlhpedg.co.uk> cl@dlhpedg.co.uk (Charles Lambert) writes:
>>>We have called this operation "reconciliation";  clumsy - any offers?
>>Yeah, call it "programmer's hell".  ...
>Better yet, call it "unnecessary".  ...
>The solution is a configuration management system
>wherein only one person can work on a module at a time.  In order to work
>on the module they have to check it out of the system in such a way that
>no one else can check it out until it's been checked in again.

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?

Parallel development paths may have the danger of conflict, but proper
management and tool support can minimize it.  I would be interested in
hearing of any non-parallel system which cleanly supports both new
development and maintenance of past releases.