Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!elroy!mahendo!jplgodo!wlbr!scgvaxd!trwrb!desint!geoff
From: geoff@desint.UUCP (Geoff Kuenning)
Newsgroups: comp.software-eng
Subject: Re: Coordinating Software Development (long)
Keywords: configuration management, sccs, project control, RCS
Message-ID: <1664@desint.UUCP>
Date: 31 Jan 88 22:39:10 GMT
References: <2457@orca.TEK.COM> <1713@ttidca.TTI.COM> <1315@vaxb.calgary.UUCP>
Reply-To: geoff@desint.UUCP (Geoff Kuenning)
Organization: Interrupt Technology Corp., Manhattan Beach, CA
Lines: 21

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,
> ...
> 
> 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.

RCS supports this very nicely;  you simply create a branch for the bug fix
while development continues on the main path.  RCS even provides the "-j"
switch (admittedly a very hard switch to use correctly) to help you merge
that fix back into the main branch later.  (You can also use System V's
sdiff program, or Larry Wall's patch program, to achieve similar results).

I believe you can also do this with SCCS, though I haven't personally
created an SCCS branch while another revision was actually checked out.
-- 
	Geoff Kuenning   geoff@ITcorp.com   {uunet,trwrb}!desint!geoff