Closed eposse closed 1 month ago
This looks related to my solution to Issue #415. In that issue, the performance problem caused during navigation of a diff was the result of logic in EMF Compare that, for each item displayed, it navigated through all the top-level matches (which was 481 in BasicPubSub), and doing this recursively. Hence my solution was to prune that list of items, which worked well in the EGit Merge Tool, but I think that in the context of the Synchronize perspective it results in pruning too much, which in turn means that the left and right panels are empty. However this is still a bit of speculation. I'm still testing to confirm it.
Also, while testing I realized there is an interesting and strange difference between the results of comparing with EGit (in the Git perspective) and with the Team/Synchronize perspective. While it is not essential to this bug, it is interesting to note, as it may have some consequences for how users see the results of a diff.
In my sample model, I'm comparing two branches, each of which has a property called "Property3", but the type associated with it is different in both branches. In the Team/Synchronized Compare Editor, this is displayed as a conflict. But in the Merge Tool launched from EGit, it is displayed as two changes: removing the Property with one type and adding the Property with the other type (in the left panel, and the dual in the right panel). Specifically, in one branch we have Property3 with type CXFloat and in the other branch we have Property3 with type CXDouble, and the diff shows, on the left panel, Property3:CXDouble removed and Property3:CXFloat added, while on the right panel it shows Property3:CXDouble added and Property3:CXFloat removed.
It is not entirely surprising that these results are displayed differently, as the compare/merge viewers in the two scenarios are different. But it could be confusing. Specially since it is possible to see conflicts in the EGit Merge Tool. So what is not clear is which cases does the EGit Merge Tool consider as conflicts and why it doesn't consider this example a conflict.
I think this bug is related to Issue #501. Apparently Papyrus Compare is filtering out non-root elements from the compare view panes, when the difference is a containment reference change, but this filtering occurs only in the Synchronize view/Compare Editor and not in the Merge Editor launched from EGit because in the first case, Papyrus Compare is loaded, but in the second case it is not. I'm not certain of this but that seems to be the case.
In any case, I think that the solution to this bug at least, would be to change the filtering that Papyrus Compare does. I need to do more debugging and experimenting.
The commits above fix the problem. I've tested on both v2 and v3. Would you like to test it or should I merge them?
You can merge them
Issue and tracking information
Developer's time Estimated effort to fix (hours):
Developer's Actual time spent on fix (hours)
Issue reporter to provide a detailed description of the issue in the space below
When comparing the local, checked-out branch with another commit using the Synchronize perspective, the contents of the left and right panels (by default local and remote respectively) are empty if the element change selected is not an incoming conflict change (remote to local/right to left red arrow decorator).
Steps to reproduce
Expected result
The left and right panels should display the elements changed in call cases, regardless of the kind of change.
Actual result
The left and right panels display the elements changed only if it is an incoming conflicting change. In all other cases, the panels are empty.
Environment
Papyrus CX 2.6 (Papyrus 4.8)
Additional info
Incoming conflicting change selected:
Other change selected: