"Jonathan S. Shapiro" wrote:
>
> > The rule is, the person merging has to resolve the conflicts. In this
> > scenario, what should happen is, my attempt to merge after monty shows
> that
> > (All but one of Monty's diffs in JCR are a NoOp), and the last one he made
> > gives me an update conflict which I must resolve in order to check in. I
> > can resolve it either by updating JCR with Monty's last diff (Wasn't that
> a
> > movie from the 1940's?) or by using my authority to alter BL and either
> > keep or remove Monty's diff as I'm adding mine.
>
> I understand the theory. The question is: what history needs to be tracked
> in order to get this right, and how is the integration algorithm to go about
> constructing the integration diff?
>
> Actually, the case you raise isn't that bad. The really tough nut comes if
> you take Monty's changes 3,4, and 6 of 7. If you do this kind of thing,
> merely applying the missing diffs will often break things.
Which is why TeamNet users typically had a work area just for seeing whether they could build after a merge. We called this the "merge area."
> Also, suppose you do this and check it in first. What happens when *Monty*
> then does a join?
Same thing. Whoever checks in last has to resolve the conflicts.
>This would seem to require recognizing which changes have
> already been incorporated.
Not really, since any time you attempt to check in, if any conflicts are detected you get bounced into your diff tool.
Now, one thing that diff tool needs to be able to do, is show you the differences between your version, Monty's version (IOW, the version that is now in BL), and the common ancestor of both of the modified versions.
All that being said, these problems tend to minimize when users get in the habit of organizing their code and their work assignments reasonably. Although TeamNet didn't have a "checkout" in the RCS/CVS sense (it didn't copy the file anywhere), there was something that we called a checkout, which was in fact simply setting a flag that said "JCR is working on this file, so be advised that if you modify it in the meantime, you're likely to have to resolve a conflict when you check it in."
-jcr