Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

EMF Compare/Logical model support

The goal is here to provide a decent implementation of what is called "logical model" in Eclipse. The word "model" in "logical model" has nothing to do with the EMF concept of model.

For more details about how logical model support has to be implemented relating to Team, you should read the document Team Support for Logical Model Integration.

First prototype

We have implemented two of three extension point from the Team Support for Logical Model Integration document. We managed to be called by CVS by adding an "enablement" (it is valued to false by default).

We then tested the three SCM shipped with Eclipse release trains: CVS, SVN, Git. Conclusions are:

  • CVS: the code is called consistently from everywhere (Compare With, Synchronize, Commit, Update, ...)
  • SVN (Subversive): the code is only called from the "Synchronize with repository" action on a folder. Compare With/Synchronize on a single file does not call it.
  • Git: tested with a local and distant repository. We are (consistently) called from nowhere: push, pull, revert, fetch, compare with, diff...

The API give us the ability to solve some problems we already (mis)addressed with the "Compare entire resource set" action. Sadly, it is not compatible with this behavior. We may not any longer be able to give the choice to the user between the comparison of the single resource and the entire resource set. This legacy action has been implemented to simulate something similar to the logical models (do a resolveAll, see that more than one resource is loaded and try to ask to the team API to give us those other resources in the well suited revision...). So far, these two mechanism could not co exist in EMF Compare. Eventually, replacement of the legacy action by logical models should give us the ability to insure the integrity of merge, update, commit... operations (i.e. no more model corruption).

Back to the top