Home » Modeling » Compare » Complicated emf model and history(Complicated emf model and history)
|
| Re: Complicated emf model and history [message #1731930 is a reply to message #1731503] |
Wed, 11 May 2016 07:36   |
|
Hi,
Quote:To resolve both models, i use org.eclipse.emf.compare.ide.ui.modelDependencyProvider extension point. But, as far as i understand in ComparisonScopeBuilder.java, that extension works only for comparison local files. Emf compare 3.2.0.
Actually it shouldn't be necessary to use the modelDependencyProvider if the models refer to each other (A <-- B). When A or B is compared, depending on the configured resolution scope in the EMF Compare preference "Resolution strategy", the model resolver will detect that one refers to the other and include both in the comparison scope. The modelDependencyProvider is only used when you want to have both models in the scope also if they don't refer to each other.
Quote:1) Is it possible to resolve both models for git revision?
Yes... with limitations: the model resolution is only performed when comparing git revisions (branches, tags, commits, etc.) with the workspace, and the model dependency detection will mainly be performed on the workspace side. When comparing with the workspace, the model resolution works roughly the following way: it will resolve all model dependencies in the local workspace (-> list of dependent model files), then it will check for each of these model files if there are additional dependencies on the remote side (-> potentially additional dependencies, such as new model files), and then it will go back to the local side and see if these additional dependencies imply even more dependencies in the local workspace. Finally, they are all put into the comparison scope.
Quote:2) Is it possible to resolve both models for file local history?
No, unfortunately not.
Hope this helps,
Philip
--
Philip Langer
Get professional Eclipse developer support:
http://eclipsesource.com/en/services/developer-support/
|
|
|
| Re: Complicated emf model and history [message #1731947 is a reply to message #1731930] |
Wed, 11 May 2016 08:41 |
 Hleb Albau
Messages: 7
Registered: May 2016 |
Junior Member |
|
|
Hi, thank you for answers.
Quote:Yes... with limitations: the model resolution is only performed when comparing git revisions (branches, tags, commits, etc.) with the workspace, and the model dependency detection will mainly be performed on the workspace side. When comparing with the workspace, the model resolution works roughly the following way: it will resolve all model dependencies in the local workspace (-> list of dependent model files), then it will check for each of these model files if there are additional dependencies on the remote side (-> potentially additional dependencies, such as new model files), and then it will go back to the local side and see if these additional dependencies imply even more dependencies in the local workspace. Finally, they are all put into the comparison scope.
(A <-- B)
So, as i understand, if some value in model A was changed and committed on remote, when comparing this revision and workspace on B files, this changes will be invisible?(instead of revision A, in scope will be workspace A)?
Hleb
|
|
|
| Re: Complicated emf model and history [message #1732549 is a reply to message #1731947] |
Wed, 18 May 2016 01:05 |
|
Quote:(A <-- B)
So, as i understand, if some value in model A was changed and committed on remote, when comparing this revision and workspace on B files, this changes will be invisible?(instead of revision A, in scope will be workspace A)?
Yes, given that also in the workspace version the model file B referenced model file A. And of course, assuming that the resolution scope configured in the preferences of EMF Compare doesn't cut away the model file A.
Best wishes,
Philip
--
Philip Langer
Get professional Eclipse developer support:
http://eclipsesource.com/en/services/developer-support/
|
|
| |
| Re: Complicated emf model and history [message #1733065 is a reply to message #1732960] |
Tue, 24 May 2016 08:03 |
|
Hi,
There seems to be enough information to understand your use case, but it's all over the place, so I'll try and summarize it, please correct any mistake in my assumption :
- You have a model that is logically comprised of two physical files A and B. The link between the two is only from B to A.
- The versions look something like this :
commit1 -----> commit2
A1-B1 -----> A2
i.e. files A and B were commited together in a first commit, and only A changed in the second one.
- Your local version is on "commit1", one commit behind the remote.
- You've modified your local version of B and now have version B2 of that file.
In such a scenario, if you launch a comparison on B with commit2, the local side will be A1-B2 (modified version of B and unmodified version of A), the ancestor will be A1-B1 (commit1) and the remote version will be A2-B1 : since we know from the local side that "A" is in your logical model, we will resolve "A2" since it is the version of that file on the version you're comparing with.
All in all, please tell us if something doesn't work as expected instead of trying to work it out on an imaginary scenario, as that will be much more clear for both of us  .
Regards,
Laurent Goubet
Obeo
|
|
| | |
Goto Forum:
Current Time: Fri Apr 19 23:29:43 GMT 2024
Powered by FUDForum. Page generated in 0.03202 seconds |
] 
Search
Help
Register
Login
Home
