Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cwjcc!ukma!xanth!mcnc!duke!romeo!crm
From: crm@romeo.cs.duke.edu (Charlie Martin)
Newsgroups: comp.software-eng
Subject: Re: Source Code Control
Keywords: NSE DSEE Sun
Message-ID: <14885@duke.cs.duke.edu>
Date: 4 Jul 89 21:29:46 GMT
References: <133@tirnan.UUCP> <39400029@m.cs.uiuc.edu> <10217@polya.Stanford.EDU> <18MZ02qG393v01@amdahl.uts.amdahl.com> <10295@polya.Stanford.EDU>
Sender: news@duke.cs.duke.edu
Reply-To: crm@romeo.UUCP (Charlie Martin)
Organization: Duke University CS Dept.; Durham, NC
Lines: 30



In article <10295@polya.Stanford.EDU> maslen@polya.Stanford.EDU (Thomas Maslen) writes:
>In article <18MZ02qG393v01@amdahl.uts.amdahl.com> johnm@uts.amdahl.com writes:
>>The problem of merging/reconciling revisions made by different people
>>still involves human interaction in NSE....
>
>>The essential difficulty with any form of auto-merge is not handling
>>the case of two developers revising the SAME LINE of source. It's
>>really how to ensure that Jack's change to line 25 is FUNCTIONALLY
>>COMPATIBLE with Jill's change to line 75.
>
>Wot he said.  Remember the failure rate of previous cooperative
>efforts by Jack and Jill.  Seriously, if anyone has any insights on
>this, I'd like to hear about them too.

Assuming that "functionally compatible" means "doesn't break anything
that wasn't already broken" this could be pretty troublesome, since
it's equivalent to deciding equivalence.  I suspect that absent a
program-proof facility and maintaining the proofs over changes, the
*best* that can be done is run regression tests automagically.

i hate mailers that
dont have any room
to allow one to include sufficient context
in the body of the 
article.  never trust
a program that thinks its smarter
than you are.
Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm)