Difference between revisions of "EMF Compare/Logical model support"

Revision as of 03:37, 20 April 2011

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. Sometimes in this document, we'll talk about logical resources interchangeably.

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

Context

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).

Conclusions

The logical model support is great piece of engineering. Out of team, it is called on delete, move, save... actions. In team, it is called from everywhere in CVS (commit, update, synchronise...). Actions on fragmented models can really be applied atomically. But:

• To fullfil the contract of logical model, we will need to browse the whole EMF model three times during each [commit/update/...] operations: local, remote and ancestor. For instance, let's have a model A depending on local fragment B and C. I select A and ask to commit it. We need to browse it entirely to discover its two fragment B and C, then we need to get A' on the server, browse it to discover its two fragment B' and C' , download those two fragments and browse them to check if they do not depend on other fragments. Then, we have to do the same thing with the ancestor of A and A'. It can be very time consumming on very big models.

• Computation is done outside EMF Compare. We have to determine what is given to EMF Compare in the case we have this kind of thing as input. Moreover, is it really feasible to accept ResourceMapping instead of Resource with our current architecture? Currently, EMFCompare is computing the differences when the comparison editor is opening... this may be too late. Eclipse Compare should provide a specific API to compute the diff before the opening of the editor... We have to investigate on this side.

• The API of logical models is happening before comparison algorithm. We then have to define how to isolate "scopedMapping" algorithms et linked resources searching within EMF Compare. ScopedMapping contributed last year by Itemis must be adapated to fit our future implementation of logical models.