Community
Participate
Working Groups
Background: Jazz uses the 3-way compare editor for merging incoming changes in the presence of gaps. This works well, but if the user's current file is different than the predecessor for the change being merged, such differences are shown as an outgoing change. Such changes are never interesting and - even though we open a dialog to explain what is happening before opening the editor - many users find them confusing and have filed bugs about it. Enhancement request: Please provide API such that the code that opens a compare editor may request that outgoing changes be hidden. Doing so would show the incoming changes and conflicts, but the black-bordered regions normally used for outgoing changes would be omitted. The text in these regions would be drawn exactly as though the text were unchanged.
There are two potential resolutions of the problem. One is to hide outgoing changes only at the presentation level. It would work like some kind of filter similar to "Incoming mode" in the Synchronize View. But all the differences would be taken into consideration for example when generating patches from compare editor. The second option is to omit computing outgoing changes at DocumentMerger level. In this case patch generated from compare editor would reflect only marked changes, not the physical difference between inputs. Stefan, what do you think about it? The second question is how to enable compare API's clients to use that setting? Is adding setShowOutgoingChanges(boolean) method to org.eclipse.compare.CompareConfiguration good for you?
I think it would be easiest to hide the outgoing changes at the presentation level. This would also make changing modes faster (i.e. you wouldn't need to do a complete recomputation of the diff if a user choose to hide outgoing changes. As for the changes to CompareConfiguration, the method you suggest would certainly meet our needs but I wonder if it would be worthwhile to have the ability to hide incoming changes as well. The flags on the Differencer class could be used to indicate the direction so the call could look something like CompareConfiguration.showChanges(Differencer.RIGHT | Differencer.CONFLICTING) which would only show changes in the right pane (e.g. incoming and conflicting). One could then OR the flags together to get a combination of changes (e.g. CompareConfiguration.showChanges(Differencer.RIGHT | Differencer.ADDITION). This is basically an inclusion filer. An alternative would be to use an exclusion filter as well (i.e. hideChanges instead of showChanges).
Created attachment 122922 [details] Patch_v01 Note that this patch doesn't give an ability to dynamically switch changes visibility since as I understand there is no such a requirement. However if such a requirement was demanded in the future there is a possibility to introduce it without API change (all the API additions are already in the proposed patch). So, using CompareConfiguration.setChangeIgnored(int, boolean) has effect only when called before differences recalculation. Tom, will you review it?
If I understand comment 3, you are saying that the type of changes being shown cannot be changed once the compare editor is opened? This is not a requirement mentioned in this bug but it is requested as part of bug 251194 and is, IMHO, a very important feature as the screenshot on bug 251194 illustrates, without this feature, the compare editor becomes almost unusable in resolving conflicts when there is a large number of outgoing changes. In that scenario, it is the user that would need to be able to hide the outgoing changes.
Mike, the patch I attached in comment 3 places the filtration inside doDiff() method. That means you could set type of changes being shown at any moment but after that differences recalculation would be needed. What I don't know is whether the fix for bug 251194 would make this new API unnecessary? What is your exact use case? If those two bugs are separate issues, we are going to release the fix from comment 3 now and do some internal changes to it while fixing 251194.
The extreme case is that which has a large number of outgoing changes (e.g. 1 per line) and a small number of conflicting changes (e.g. 1). In that scenario, it is impossible to find the conflict any other way except scrolling the compare editor until you find it (as illustrated by the screenshot on the bug. Although the screenshot just looks like a bunch of outgoing changes in the birds-eye-view, there is a conflict in the file).
So, resolving bug 251194 will make this API request invalid. Right?
No, in some cases, the repository tooling knows that outgoing changes aren't interesting (e.g. when dealing with patches) and in other cases, the user knows that outgoing changes aren't interesting (e.g. when trying to resolve conflicts in a file with a large number of outgoing changes). Both the API for repository providers and a button (or whatever) for users are important (IMHO).
Created attachment 123059 [details] Patch_02 I inlined the getKind(int) method Pawel added in the previous patch into the useChange(int) method which already exists in DocumentMerger. It seems to be a better place for checking whether we are interested in a given type of change.
Created attachment 123060 [details] mylyn/context/zip
(In reply to comment #9) > Created an attachment (id=123059) > Patch_02 Released to HEAD.
