Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Compare » EMFCompare's EGit Recursive model merger(Question over EMFCompare's extension of Git merge strategy. )
EMFCompare's EGit Recursive model merger [message #1723080] Thu, 11 February 2016 12:43 Go to next message
Luis Mendes is currently offline Luis MendesFriend
Messages: 7
Registered: August 2015
Location: Denmark
Junior Member
Hello,

I'm using the EMFCompare with EGit in order to provide collaborative modeling and support the sharing and merging of EMF model instances (serialized in XMI). I'm also using the latests Integration Builds from the EMFCompare update site for both EMFCompare and EGit : http://download.eclipse.org/modeling/emf/compare/updates/logical/emf.compare/integration and
http://download.eclipse.org/modeling/emf/compare/updates/egit-logical/integration

I'm currently aware that EMFCompare contributes it's own EGit Recursive Model Merger that, as far as my understanding goes in this point, will iterate sequentially through all the git working tree files, in the case of a EGit merge operation or EGit operations that involve a merge operation, and will try to determine if a certain file is part of a logical model and try to construct/complete the Logical model graph like this in order to do model merging.

My questions are:
1) Is the above reading of the EMFCompare Recursive Model Merger functionality correct?
2) Having into account the above reading, are you aware of any way to influence this iteration, over the git working tree files, and direct the logical model assessment and graph construction to start on a certain file or files (that we know in forehand that are the root container of the EMF model instance) ?

The purpose of this question is to try to determine if, in the case of large EGit working trees due to both large model file (size of the each XMI file) and widely decomposed models (models that spread several XMI files), we can somewhat improve the performance of the logical model construction during EGit merge operations by pinpointing directly from where to start the logical model construction.

Thank you very much in advance for your time.

Best regards,
Luis Mendes
Re: EMFCompare's EGit Recursive model merger [message #1723161 is a reply to message #1723080] Fri, 12 February 2016 09:23 Go to previous messageGo to next message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1857
Registered: July 2009
Senior Member
Hi Luis,

You are right about the model resolution strategy. The best doc we have about the resolution process is https://www.eclipse.org/emf/compare/documentation/latest/developer/logical-model.html which sadly doesn't touch the git part.

Unfortunately, there aren't many ways to influence this. We have few mechanisms in place in order to alter the model resolution behavior (apart from the possibility of replacing it as a whole, which isn't really desirable).

However, we are very interested in hearing your thoughts about how to change this and what kind of extensions you have in mind, and willing to work with you on setting up the necessary mechanisms. Would you mind giving us more details about your use case and the means you're thinking about to improve the model resolution phase?

If necessary, we can setup a call-conference if it would make things easier to communicate on the matter.

Laurent Goubet
Obeo
Re: EMFCompare's EGit Recursive model merger [message #1723476 is a reply to message #1723161] Mon, 15 February 2016 22:02 Go to previous messageGo to next message
Luis Mendes is currently offline Luis MendesFriend
Messages: 7
Registered: August 2015
Location: Denmark
Junior Member
Hello Laurent,

thank you very much for your reply.

The Use Case is the following (where the EMFCompare's Recursive model merger is being triggered):

UC #5 -- Integrating collaboration changes (large models)
Description: The User triggers the Git Pull operation via right-clicking on the repository in Git repositories view and selecting "Pull".
Preconditions: A Git repository exists locally and is associated to a Git remote. It was created by cloning a remote repository at some point in time with only one
working branch (master). The Git repository is visible in the Git Repositories view of EGit. EGit Synchronization options "Allow models to participate in synchronizations" and
"Recursive Model Merge Strategy (from EMFCompare)" are set. In the remote repository there are new commits (desynchronized repositories).

Step 1 - The User opens the Git Repositories view;
Step 2 - The User selects the Repository and triggers the repository context menu by right-clicking;
Step 3 - The User selects the "Pull" option of the repository context menu;
Step 4 - The User inserts EGit authentication information;
Step 5 - The User visualizes the Fetch and Update results;

Postconditions: The local repository is now updated with the latest changes over the model currently being built.

The above use case will trigger the execution of the Recursive model Merger of EMFCompare and it will do so
on a Git working tree with the following structure (in my particular case):

  • Workspace

    • project

      • .git
      • modelfragment1.xml
      • modelfragment2.xml
      • modelfragment3.xml
      • modelfragment4.xml
      • modelfragment_main.xml
      • modelfragment5.xml




Due to some performance penalties when the models are decomposed into several fragments and large fragment sizes, what I will try, with the purpose of assessing how would a Recursive Model Merger behave performance-wise on the execution of the above use case, is, instead of iterating sequentially through the revision tree, to search objectively for a certain file (physical resource) that we know in advance it is the file that contains the root of the entire model (in the above structure is the "modelfragment_main.xml" file) and that the whole logical model and resources graph can be reached or transitively reached by references from that physical resource ("modelfragment_main.xml" file that has the root container element).
It might be fair to think like this since we are aware that all the files in the revision tree (and in the repository) are part of a
single/one logical model, and no files/resources will be defaulted to the JGit Recursive Merger.

If nonetheless you have any thoughts/ideas on how to avoid linear scaling between size/decomposition of models and EMFCompare Logical Model generation, on the integration with EGit, please let me know.

Best regards,
Luis Mendes
Re: EMFCompare's EGit Recursive model merger [message #1723820 is a reply to message #1723476] Thu, 18 February 2016 09:20 Go to previous message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1857
Registered: July 2009
Senior Member
Hi Luis,

One of the mechanisms that already exist in EMF Compare might be sufficient to handle your use case.

Basically, what will happen in your case is that egit will iterate over your files in order : fragment1, then fragment2, then fragment3... seeing the main only last (or first, depending on the ordering, if they are named that way). For each file, git will delegate to EMF Compare to try and determine the logical model. Since all of your files are part of the dame model, only the first matters (since we'll explore all files in the same folder by default, see the resolution scope preference of EMF Compare). Depending on that resolution scope, we'll either start directly from what git feeds us (the fragment1 file in the above exampe) or "go up" to its container, project, or the whole workspace. From that "starting point", we then browse through and sequentially resolve the files and their outgoing references (if the files are models) to populate our registry of logical model. The thing is : we go in order... but extenders have a way to give us "other" dependencies for each files, dependencies that will be resolved themselves as soon as possible when an extender gives them to us.

In the case of papyrus files for example, the models always go three by three : model.uml, model.di, model.notation. There is a custom dependency provider that tells EMF Compare that it can resolve all three asap instead of waiting until we see them through our sequential browsing of the containing folder.

You might use the same kind of extension to tell EMF Compare that there is that "_main" file that it can resolve asap when you see a model file that corresponds to something you know. We will still load one of the fragments first, but you'll be able to tell us to do the main next so the rest of the logical model will be seen and loaded right afterwards. I am not entirely sure this will make your use case much faster, since we'll still have to load the fragments in order to know which are candidates for differencing and which can be ignored altogether in the comparison... But at least we'll know where the fragments are and will load them asap. It might be worth a try.

This is accomplished through implementing org.eclipse.emf.compare.ide.ui.dependency.IDependencyProvider and providing it through the org.eclipse.emf.compare.ide.ui.modelDependencyProvider extension point. You can check an example implementation with what we've done for Papyrus in org.eclipse.emf.compare.diagram.ide.ui.papyrus.dependency.PapyrusDependencyProvider .

Please let me know if this does indeed answer your use case.

Regards,

Laurent Goubet
Obeo
Previous Topic:Merge Mode in EMFCompare + EGit
Next Topic:Custom Matching Strategy
Goto Forum:
  


Current Time: Thu Jul 19 09:33:38 GMT 2018

Powered by FUDForum. Page generated in 0.02972 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top