Community
Participate
Working Groups
When you have conflict during update of sources from CVS, and you try to resolve it by manually copying changes to local file, there is no possibility to force Eclipse to reevaluate it (even when there are no more changes in remote file) and remove conflict markers. Restarting workspace helps though. Screenshot included.
Created attachment 79803 [details] Conflict solved but Eclipse still shows red cross
Antek, have you tried using "Mark as Merged" action from the context menu? Does it come in handy? Or are you referring to the Java Structure Compare part of the Compare Editor from your screen shot? Is your claim about the part not being updated (reevaluated) when all conflicts are resolved? BTW, I'm not sure if restarting Eclipse actually helps here.
Mark As Merged is not solution of this problem, because it requires developer to make decission that all conflicts have been resolved. What is my intention is to have Eclipse help me make this decision by recomparing the current state of local and remote sources (like it does when I choose the option "Synchronize with repository" for the first time), so it is possible to be sure that all necessary changes from remote version have been copied to the local version (currently Java Structure Compare shows all the initial conflicts no matter if they do or not exist any longer).
Antek, if I understood you correctly your request is similar to the Stefan's one in bug 202944 (points 2 and 3). The difference is that he is referring to an "auto-merge" feature and you're talking about a result of a manual merge. Please, correct me if I'm wrong, but I don't think that having "all necessary changes from remote version copied to the local version" is the only condition for marking the change as merged. I can imagine this kind of workflow: 1) The user got a conflicting change 2) He decides to copy the change from right (remote) to left (local), which results in having both (conflicting) pieces of code on one side 3) The user saves changes 4) Referring to your proposition, the compare mechanism now decides that the change is no longer a conflict and the markers get updated What should happen if the user changes the part which has just been copied from the remote file? Should we mark it back as a conflict? What if a valid result of the merge is only when only a part of the remote change is copied into the local file? Then, you will have to mark it as merged manually. I'm afraid that this will lead us to a conclusion that any modification made (on the local file) in the conflicting change should result in marking the change as outgoing (instead of conflicting). Am I right or did I miss something?
Basing on a conversation I've had with Antek, I think we finally agreed what this bug is all about. The problem is that neither Sync View nor Java Structure Compare update when a conflict is resolved. What I mean by "resolved" is that a change from a remote file has been copied into a local file and replaced the local change. After saving the file, the Compare Editor is updated (the conflicting change disappears) but the Sync View and Java Structure Compare (if it's a CU) are still showing red markers indicating that there's a conflict. This seems to be a reminiscence of bug 12232... and there are probably more bugs related to this issue, nevertheless I will mark this one as ASSIGNED to indicate that it's a valid bug.
Pawel, isn't this a different use case for the "auto-merge" button from bug 202944?
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.
