Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!agate!shelby!polya!maslen
From: maslen@polya.Stanford.EDU (Thomas Maslen)
Newsgroups: comp.software-eng
Subject: Re: Source Code Control
Keywords: NSE DSEE Sun
Message-ID: <10295@polya.Stanford.EDU>
Date: 28 Jun 89 05:19:21 GMT
References: <133@tirnan.UUCP> <39400029@m.cs.uiuc.edu> <10217@polya.Stanford.EDU> <18MZ02qG393v01@amdahl.uts.amdahl.com>
Sender: Thomas Maslen <maslen@polya.Stanford.EDU>
Reply-To: maslen@polya.Stanford.EDU (Thomas Maslen)
Organization: Stanford University
Lines: 26

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. As far as I can see, the
>essential difference in NSE is the human interface with the person
>doing the merging job. It seems that, in most auto-merging systems,
>data is assumed to be "auto-merge"able unless the two revisions
>hit the same lines of code. When that happens, then the human
>controller must make a decision. NSE does appear to make this
>operation fairly user-friendly.

Right.  I shouldn't have used a nebulous phrase such as "(largely automated)".
My apologies to anyone who was misled.

>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.  In the absence of anything
smarter, it's good to have a system that insists on regression-testing
things before blessing them as official revisions, but that's assuming
rather a lot about the tests.

Thomas Maslen					    maslen@polya.stanford.edu