Community
Participate
Working Groups
I have the following problems: After adding/updating files and commiting my changes to CVS, my HDD failed. I restored my local data from a previous backup, taken just before the commit. Now all the committed files show as conflicts in the synchronize view, even though the Java Source Compare can't find any. However, the Java Structure Compare also reports the fake conflicts. I had to manually fix this by override and update, and this is very annoying, since the commit included many files, and I had to check each one by hand, to see if the conflict is real or not. This also happens if somebody sends me some files by email to patch my source tree, then he/she later adds it to CVS. Even though the files are the same, a conflict is reported. Under some circumstances, I also experience the behaviour from bug 82437 (Synchronize view shows conflicts on unchanged files). I think this could happen if you perform an update for a file modified by somebody else on the CVS server, but for some reason (IDE crash - i had a lot of those with 3.2.1 on Vista, OS crash, permission issues, whatever) the local CVS subfolders are not updated . All this problems make using CVS from Eclipse a pain...
Created attachment 69887 [details] Fake conflict screenshot
The proper CVS workflow for recovering from this type of failure is to perform a Team>Synchronize followed by an Update. This should reset the timestamps of all files whose contents match the server.
I tried to reproduce your workaround, so I tested with one file, queries.xml, version 1.4. The remote version was 1.5, commited by somebody else. I opened the file in compare view, and I copied the 1.5 version to clipboard, then I closed the IDE. Then, I replaced the contents of the local file, with the 1.5 version from the clipboard. I opened the IDE, and from the Project Exporer I refreshed the project. Then, from the synchronize view, I selected "Populate", and the file showed with a "conflict" icon and a "1.4 - 1.5" annotation. I doubleclicked on the file, the compare editor didn't show any differences in the Text Compare area, but showed some conflicts in the XML Compare area, even though the two files were identical. Then, as you suggested, I clicked synchronize, nothing changed, then i ran update, and the icon changed from "conflict" to "outgoing changes", and the annotation from "1.4 - 1.5" to "1.5 - 1.5". I reopened the file in the compare editor, and now it didn't show any structural or text differences or conflicts. So the problem changed from "Fake conflics" to "Fake outgoing changes". I tried to update again (I received a "no changes to merge" message), and nothing changed. Then I synchronized again, and finally the file disappeared from the synchronize view. So, "the proper way to recover" is Team>Synchronize followed by an Update followed by a second Team>Synchronize. I feel this is too complicated and counter-intuitive. And I'm worried about the effects the update operation could have on files containing real conflicts, so for now I will still check each file by hand before running update, to see if the conflict is real or not. I think a better solution for this kind of situations should be implemented. One solution would be to modify Team>Synchronize to detect and solve fake conflicts (maybe with a confirmation dialog), or, if this would slow down synchronize, make this operation an additional option in the context menu of the synchronize view, named "Fix fake conflicts".
I agree that a single Team>Synchronize should fix the problem. Unfortunately, we don't have a lot of manpower at our disposal so I doubt we will have time to address this. We would be happy to accept a patch.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
