Comparison of two commits (diff)

[Phillipus]

Before handling merges I'm working on how to display the difference between two commits, or one commit and the "working tree" (uncommitted changes).

At the moment all new code is in the dev branch (which is continuously being updated and force pushed.

This is how it looks now:

Selecting a View shows a visual comparison as we do it in coArchi 1.

But a View can appear twice if it is added:

1. As an addition to its parent folder ("ADD")
2. As a parent object with all of its child objects shown as ADD and CHANGE diffs

Also, changing the name of a concept will show twice:

1. As a CHANGE to the concept
2. As a CHANGE to where it appears in a View

So, the tree at the moment is a "raw" view of all changes, additions, deletions of objects and their parent objects. We need to change this so it makes more sense.

[Phillipus]

Maybe there is some tuning to be done so that EMF Compare doesn't take such EMF classes into account.

EMF Compare will provide every single Diff between the given models. We need to process and filter this information to create our own diff model (see class ModelComparison).

[Phillipus]

@jbsarrodie I've been stuck on this problem for the last few weeks and need some design help. ;-)

I can get all of the pieces of the puzzle from EMF Compare which provides us with several Diff classes when comparing two models:

• We have a Diff
• The Diff has a Match
• The Match gives us a Left (current) and Right (previous) object from the current and previous models
• If Left is null the object was deleted
• If Right is null the object was added
• The Diff can be an:
  • ReferenceChange: a child object added/deleted.
    getValue() returns this child object.
    This child object can be an element, relation, profile, feature, bounds.
  • AttributeChange: an existing attribute of an object is changed.
    getAttribute() is used get the attribute to get its value from left or right.

So, as can be seen from the screenshot above we have a lot of literal information.

• How to present this?
• How much detail do we present?
• Can it all be displayed in a TreeTable? Perhaps we need to show additional panes for text?
• The presentation has to be generic. In coArchi 1 we showed merge conflicts with custom controls for name, documentation, properties. But that's not sustainable as we add more features to Archi. We need to show all changed attributes, features and so on (profiles, line width, gradient, label expressions for example)

I've spent some time trying different approaches and fail each time. I also tried presenting it like the model tree, but that failed because you need to show two trees (left and right) and that became cumbersome and complicated.

This is an important feature for coArchi 2 and we'll need to use it when handling merge conflicts.

[Phillipus]

@jbsarrodie I'm back to this again. I'm trying a new approach to getting the changes of an object. For example, if a concept is added to a folder we want to see that concept at the high level in the changes tree, not the parent folder. However, the problem remains - how do we show multiple changes to an object?

This screenshot shows the following changes to a "Gap" concept:

1. Added some documentation
2. Add a new property
3. Renamed "Gap" to "Gap Renamed"

Do we want to show these changes in the tree? Or somewhere else? Or differently?

[Phillipus]

We could show the changes of an object in a separate table below the tree. The disadvantage of that approach is the user has to click on each object to see the changes. The advantage is it is less cluttered.

[Phillipus]

This has turned out to be so complicated that, after months of working on this and going wound in circles, I've failed to come up with a working solution. I'm going to have to abandon this and just say "something changed."

[jbsarrodie]

This screenshot shows the following changes to a "Gap" concept:

This is very similar to what I had in mind. I should be able to find some time this week to check it and contribute some code.

This has turned out to be so complicated that, after months of working on this and going wound in circles, I've failed to come up with a working solution. I'm going to have to abandon this and just say "something changed."

Let me have a look first, I'm sure what you've done so far is quite usable ;-)

[Phillipus]

@jbsarrodie Thanks.

I think the problem is that one model transaction can create so many Diffs under the hood that it's difficult to either filter these or combine them to show something friendly. For example adding a new element to a view creates 4 Diffs - a new view object, new Bounds, a new reference to underlying concept, etc. Then the code becomes complicated - "If it's a certain type of Diff, and the parent is a whatever, and the reference is a whatever, and it's a Monday...." if you know what I mean. ;-)

I think for now what we show the top-level changed objects that changed. And the tree nodes should be initially collapsed. Then a power user can expand the tree nodes to see the diffs and the underlying details if they want. Then perhaps later re-visit this and fine tune it.