ZeligsoftDev / CX4CBDDS

CX4CBDDS component modeling and generation tool
Apache License 2.0
8 stars 5 forks source link

Compare on the Synchronize perspective shows only incoming conflicting changes #499

Closed eposse closed 1 month ago

eposse commented 4 months ago

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

  1. Create a model in a Git repo.
  2. Make two branches (say "a" and "b").
  3. On branch "a" make changes that are not in branch "b" (e.g. add a Property to a Class)
  4. On branch "b" make changes that are not in branch "a" (e.g. add a Property to a Class)
  5. Checkout branch "a"
  6. In the Papyrus perspective, in the Project Explorer, right-click on the model.
  7. Select "Compare with > Branch, Tag or Reference ..."
  8. Select branch "b" and click [Compare].
  9. If it asks to switch to the Synchronization perspective, click [Yes]
  10. In the "Synchronize" view, unfold the project
  11. Right-click the .uml file
  12. Select "Open in Compare Editor"
  13. Navigate to find an incoming conflicting change (if there are any).
  14. Navigate to find any other kind of change, i.e. any outgoing change, or non-conflicting incoming change.

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:

compare-right-to-left

Other change selected:

compare-left-to-right

eposse commented 2 months 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.

eposse commented 2 months ago

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.

eposse commented 2 months ago

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.

eposse commented 2 months ago

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?

emammoser commented 1 month ago

You can merge them