new feature suggestion: 3-way conflict indicators

[Matthew Herrmann]

Hi All,

I have a suggestion for a new feature I think would be exceedingly useful
for difficult merges. The idea is to have 3-way conflict indicators.

THE PROBLEM:
When I do a difficult merge, i sometimes usually go off an rdiff output
while i'm tracing through the conflicts to make sure i capture the changes
properly. I find this helpful determining changes causing conflicts.

But surely, shouldn't the conflict markers themselves be adequate to resolve
a merge? (and the reason they are thrown in in the first place?) Not so. I
believe that the current system of conflict markers is subtly (and
dangerously) inadequate, and lacks some vital information to resolve
conflicts safely.

THE EXAMPLE:
Let me give an example to demonstrate the problem, and my proposed
solution...

here we have a conflict in some code after performing a bugfix merge off a
production branch onto the development trunk, shown below. Looks simple?
Someone's obviously gone and changed the indenting (note the extra spaces)
in this part of the code because they put it in a for loop, which is why the
auto merger couldn't put in the 10 => 9 change, and the i => i+1 change.

FILE:
========================================================================
... rest of file

  for (j=0; j<100; j++) {
<<<<<<<<<<<<<<<<<<<<<<<<<<<
  for (i=0; i<10; i++) {
       perform_operation(i+1);
  }

---------------------------
     for (i=0; i<9; i++) {
          perform_operation(i);
     }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
  }
  ... rest of file
========================================================================

WRONG! The change was only to change i to i+1, but the 10 should not have
been changed! 10 had been changed to 9 in the trunk, but not on the branch,
and had been done that way for good reason. But now, we have clobbered our
trunk's code change from 10=>9 (possibly now a new bug) with old code from
the bugfix branch. Incredible how such an innocent looking conflict can be
really nasty... Imagine all the bugs this could create. This shows the
fundamental weakness in using standard conflict markers to merge changes.

I reckon this weakness is the main reason why so many people on this list
(Greg for example) are horrified by code beautifiers, because they make this
kind of error really likely. Why? Not because code beautification is
inherently _dangerous_ (though some might say useless), but because it means
you need to perform conflict resolution using conflict markers, much more
often, which _are_ (IMHO).

THE SOLUTION:
How about this? Now it's obvious that the change was in fact to fix the
out-of-range error caused by i-1, and that the 9 -> 10 difference was
because of something else.

OLD UNFIXED <<<<<<<<<<<<<<<<<<<
  for (i=0; i<10; i++) {
!      perform_operation(i);
  }
FIXED -------------------------
  for (i=0; i<10; i++) {
!      perform_operation(i+1);
  }
-------------------------------
     for (i=0; i<9; i++) {
          perform_operation(i);
     }
NEW UNFIXED >>>>>>>>>>>>>>>>>>>

Now, the person merging would be very clear that only the i+1 was included
in the change, and would apply that (or something in the same 'spirit').

Please consider this, I think this would be a great idea and would add great
value to the concurrent edits model.

What do other people think? Anyone else agree, or disagree?

Note that that this effectively eliminates the _DANGER_ aspect out of the
problems in reformatting code in the trunk and causing nonsense conflicts.
It's now simply just _annoying_ and time consuming to the person merging,
rather than risking clobbering changes (although of course human error in
manual merges is still, as always, a factor, though i would argue now far
less likely, and certainly no more error prone than non-conflicting
automatic merges).

PS> We have just installed the new version of CVS... thankyou to all those
who contributed, especially Larry for incorporating the -rR1::R2 request,
appreciated.

Regards,

Matthew Herrmann
--------------------------------------
Far Edge Technology