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.
EMF Compare/EGit/Logical Model Support
Contents
Logical Model Support in EGit
This document describes the support for logical models that we would like to have in EGit
What we are trying to achieve
We would like EGit to help us manipulate models saved in several files that must be maintained in sync at all times. When commiting, we want EGit to make sure we commit together all the files that are part of a ‘logical model’ When comparing, we want to compare together all the files that are part of a ‘logical model’, even if we only right-clicked on one of them (because there’s no single UI element we can use to launch the comparison between different versions of our logical models) When merging (merge, cherry-pick, rebase, …), we want to be able to use a merge strategy that is aware of our logical models and does not just work on file granularity.
For this, we already introduced:
- A preference ‘Allow models (e.g. java, EMF…) to participate in synchronizations’
- An extension point to allow third parties to register their own merge strategies
- Some modifications to take logical models into account when comparing. This last part is not yet (as of today 2016-Sept-23) fully satisfactory, and the point of review 43528 is to improve that.
Use-Cases
The use-case we are interested in is that of logical models made of EMF files. EMF models can be saved in several files that may have references between each-other. Each tool is responsible for the way they save their models, and so each tool can define the semantics of their ‘logical model’ the way they want, even though they all save EMF models. For instance, A non-graphical UML tool may consider that a logical model is made of the set of files that contain the semantic data that describe the UML model. A graphical UML tool would consider that its logical model is made of the semantic UML files plus the files that store the diagrams (which may be stored in some kind of EMF model, or binary proprietary data, or whatever). And so on.
One thing that’s important to underline is that we are dealing with logical models for which the set of files cannot be determined without knowing the content of the files it concerns. Depending on the tool implementation, the logical model can be determined by parsing a file content, which will provide the file’s dependencies, and then parsing its dependencies recursively. In other cases, some completely unrelated source of data (another file for example) may be used to store the set of files that constitute a logical model.
EMF Compare aims at supporting the comparison and merge of any logical model backed by standard EMF resources and stored in git repositories. The Papyrus community is interested in having full support of logical models for papyrus models stored in git repositories.
Currently Known Limitations, Problems, and Open Questions
- Support for comparisons with index is missing;
- Comparisons between local and remote revision cannot handle the case where the remote revision’s logical model contains certain files that are not part of the local logical model. This is due to the use of ResourceMappingContext.LOCAL_CONTEXT which does not allow model providers to determine the remote logical model a given file is part of. That’s what review 43528 was about;
- Support for logical models when comparing from the commit dialog is missing. The comparison will occur only on the file that was double-clicked;
What is the meaning of comparing a project or folder with another version of this project/folder when they contain files that are part of logical models that cross the boundaries of the project/folder? Concrete example: I want to compare a folder that contains file A.uml, which depends on file B.uml located outside of the folder;
Useful Links
Team documents about the ‘logical model’ notion: