Community
Participate
Working Groups
A typical conflict resolution workflow in a compare editor is to copy all non-conflicting changes from left to right and then go through each conflict and resolve it. It would be nice if the compare editor supported this workflow better by: 1) providing a count of the number of conflicts in the file 2) allowing the user to visit the next conflict. 3) providing a UI gesture that would allow the user to mark a conflict as resolved. This would update the count of remaining conflicts. With these capabilities, a user could simply cycle through each conflict ans would know when they are done when the conflict count reached 0. There is already some support for this in the existing compare editor in the sense that if you perform a "copy change from left to right" on each change in the compare editor, the little square in the upper right of the editor turns from red to green. Implementing this enhancement could potentially leverage this existing functionality.
This enhancement is very important for at least a couple of reasons: - Currently, the merge tool produces a rather foreboding warning message whenever you select the "resolve as merged" operation. In the other merge tools, no such warning is needed because they keep track of whether you have merged all the conflicts. - The way in which you resolve a given conflict often depends on how you are going to resolve other conflicts in the file, and so it is very common to need to resolve the conflicts in some non-linear ordering. In the ClearCase and RSA merge tools, this is very easy, because you indicate when you have resolved a given conflict, but in the Eclipse merge tool, it is very hard to keep track of whether you have already resolved a given conflict.
What Geoff is referring to in comment 1 is a button that our SCM client adds to the Compare editor to make it easier for users to mark a file as merged when they are done resolving conflicts. To make what he is asking for possible, we would also need compare API to access the number of remaining unresolved conflicts. With this API, we could be very explicit in our warning message (e.g. "You have 3 unresolved conflicts remaining in this file. Are you sure you want to mark the file as merged?").
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. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
The problem still exists, and it would be great to get a fix. Experienced users can workaround the problem, but new users continue to be confused and make errors because of it. I couldn't see a way to remove the "stalebug" tag ... perhaps someone could do it for me, or point out how I would do so? (I'm sure it is something obvious :-).
(In reply to Geoffrey Clemm from comment #4) > I couldn't see a way to remove the "stalebug" tag ... perhaps someone could > do it for me, or point out how I would do so? (I'm sure it is something > obvious :-). Just remove "stalebug" from the text field and "Save changes". But I don't know if you can do it if you are not the bug owner. I remove the tag.
Thanks, Paul. It does appear that only the bug owner (or someone with privileges greater than mine) can remove that tag.
