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 _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs