Community
Participate
Working Groups
I'm using Eclipse Europa, and a very annoying thing is that pseudo conflicts are no longer recognized as such and thus there is a very strange behaviour in the compare view. I've attached a screenshot where the left and the right side are exactly equal (even including whitespaces), but the compare editor marks all kinds of differences. If I take out the added lines that come before this, there is no problem at all.
Created attachment 82177 [details] screenshot showing the wrongly detected "changes"
I've heard of this before and i think I know why it is happening in 3.3. Prior to 3.3, the diffs were not refreshed when a compare editor was saved. In 3.3, when the compare editor is saved, the comparison is rerun. I think that this recomputation is resulting in what you are seeing. Can you confirm that you only see the pseudo-conflicts after you save the editor?
(In reply to comment #2) > recomputation is resulting in what you are seeing. Can you confirm that you > only see the pseudo-conflicts after you save the editor? No, actually I can confirm just the opposite. I have here another file where even the line numbers match, and the content is exaclty the same, but eclipse still show differences. The bug is definitely happening no matter whether changes have been made in the editor or not. The falsely detected "changes" are also detected after eclipse has been restarted/the synchronization has been refreshed.
Can you confirm that the same conflicts do not appear in previous Eclipse releases? My theory is that the problem has become more pronounced because of the new save behavior under the assumption that user ussually edit and save the compare editor and then commit/mark as merged in the Synchronize view. However, if the behavior in the case you mentioned in comment 3 differs from 3.2 to 3.3 then my theory is incorrect.
(In reply to comment #4) > compare editor and then commit/mark as merged in the Synchronize view. However, > if the behavior in the case you mentioned in comment 3 differs from 3.2 to 3.3 > then my theory is incorrect. > Ok, here is a _very_ interesting thing I've found out: The problem per se does not show in Eclipse 3.2. _But_ it also only shows in 3.3 if the file in the compare editor has a conflict with the version from the repository. As soon as I mark the file as "merged", the incorrect markers disappear.
Sorry, a slight correction: As soon as I mark the file as "merged" /and reopen the compare editor/, the incorrect markers disappear.
I would expect that. The reason the conflicts are appearing is because both the left and right sides of the compare differ from the ancestor. Once you perform a mark as merged, the ancestor changes to match the remote so you are left with only outgoing changes (or possibly no changes). The fact that the behavior is different (i.e. better) in 3.2 means I was wrong. We did makes changes to the two-way difference algorithm but I would have expected them to affect the results of a three-way compare. Tomek, since this appears to be a regression, we should look into this for 3.4.
I must admit that I've seen this before too. The problem is that I've never managed to reliably reproduce it. Stefan, do you think it would possible to send us detailed steps which result in having the compare editor act this way. It would a perfect starter for the investigation or even writing a test case to avoid any regression in the future. I would really appreciate it.
The cause of this has been isolated and a fix released to HEAD as part of bug 210688. We will try and get this into 3.3.2 as well (needs PMC approval). *** This bug has been marked as a duplicate of bug 210688 ***
