Version: (using KDE KDE 3.2.3) The version selection buttons ('A', 'B', 'A+B', 'B+A') in the resolve dialog result in a messed up merged version. For example pressing the 'A+B' button results in merge, where the complete source of version B is inserted into the complete source of version A at the place where the conflict was. Version A --------- Line 1 Line 2 Line 3a Line 4 Version B --------- Line 1 Line 2 Line 3b Line 4 Merged Version -------------- Line 1 Line 2 Line 3a Line 1 Line 2 Line 3b Line 4 Line 4 Expected result --------------- Line 1 Line 2 Line 3a Line 3b Line 4
This occurs with me as well. Just bumped up to KDE 3.2.2.
Created attachment 6325 [details] Patches to resolvedlg This modifies resolvedlg.cpp and resolvedlg.h to correctly handle conflict files. It will fix the bug of having the selection buttons take the entire file into the diff item rather than the subsection under scrutinity. It also fixed a problem with saving. This is my first contribution to KDE and Open source for that matter. I hope this is okay.
Created attachment 6335 [details] patch to resolvedlg
The previous patch does not work correctly. SO I've fixed it but I have a special patch that basically removes bug fix 74903. This is because our coding standard uses comments using 7+ = charecters. Like C===========subroutine name==================== REAL SUBROUTINE NAME Which caused undesireable effectsin the resolve dialog. So I have reverted back to a hard 7 or nothing rule for the conflict markers. I've also swtiched to regular expression in teh hope that this could be solved in the future. (regexps are handy)
Created attachment 6336 [details] Cleaned up patch Thanks a lot for the patch! I attached a cleaned-up version. I had a different solution in mind. Your solution is more like the original code, but it seems to work pretty good. I think we should use your patch. The Bug 46871 is still fixed with the patch. Unfortunately, as you already said, Bug 74903 would be back in. The question is, which is more important: a) to handle conflicts with the markers not on a separate line like Bug 74903. b) to support content that uses the conflict markers. IMHO b) is more important and probably more common. It also makes the code simpler. We should instead offer to call a 3rd party conflict editor, like we do for the diff viewer. Any thoughts? Christian
Hey Christian, Yep I agree the Bug 74903 is a very tricky one to catch. The only way to get it is to .. 1. Determine which is the last conflict in the file. 2. determine if there are no standard "=======" then blank" conflict markers in that conflict. 3. Find the non-standard conflict markers and act accordingly. I personally think this is a cvs design flaw. If a user had a conflict like: hello <<<<<<< test.F there======= their======= chris<<<<<<< new.F There could be two possible scenarios generating this conflict. The only way to guarantee that this bug will not occur is to obtain from cvs the new version and the local version and do a comparision on the offset point with the original files but I think that would be a bit of a headache. So for now I'd drop 74903 This was fun working on though! Phylroy
Patch committed on June 16th, so the fix will be part of KDE 3.3.