Path: utzoo!mnetor!uunet!husc6!bbn!uwmcsd1!ig!agate!ucbvax!hplabs!sdcrdcf!trwrb!desint!geoff
From: geoff@desint.UUCP (Geoff Kuenning)
Newsgroups: comp.software-eng
Subject: Re: Coordinating Software Development (long)
Message-ID: <1672@desint.UUCP>
Date: 6 Feb 88 23:34:15 GMT
References: <1664@desint.UUCP> <2527@brspyr1.BRS.Com>
Reply-To: geoff@desint.UUCP (Geoff Kuenning)
Organization: Interrupt Technology Corp., Manhattan Beach, CA
Lines: 22

In article <2527@brspyr1.BRS.Com> tim@brspyr1.BRS.Com (Tim Northrup) writes:

> For this reason, we maintain separate areas for each release.  Yeah, it
> takes more disk space, and yeah you have to make the fix in more than
> one place (the release the customer has, and the next release), but
> it requires a lot less work than extracting back revisions of everything
> from from SCCS, making the fix, recompiling, and magically merging the
> fix back into SCCS (and praying that it merged it correctly).

This is pretty much what I do, except for minor variations due to disk space.
Even if you have a single area for both releases, the merge process boils
down to making the fix twice, and in either case you can use automated
tools (perhaps making a temporary extra copy of an SCCS file) to ease the
task if this is appropriate.

As to making sure the merge is correct, I do two things.  If I can use RCS,
it warns me pretty nicely about merge conflicts, leaving extra lines in
the code to help the post-edit.  And for any source control system, I diff
and eyeball the code before checking it in.  This works pretty well for
small changes;  for large ones, you're just stuck with extensive testing.
-- 
	Geoff Kuenning   geoff@ITcorp.com   {uunet,trwrb}!desint!geoff