|
Re: New UUIDs for non-conflicting Addition changes after merge [message #1751733 is a reply to message #1751682] |
Fri, 13 January 2017 09:08 |
|
Hi Monica,
This sounds like EMF Compare isn't using your IDs at all. Have you tried removing the unknowns here by comparing and merging your models directly from a standard eclipse to see if your UUIDs were preserved that way? If they are not preserved even through the normal operation (no git involved, just compare two models with each other) then EMF Compare probably doesn't manage to see your IDs (or you are computing them in a non standard way?).
Please try and check what's done within org.eclipse.emf.compare.merge.ReferenceChangeMerger.addInTarget(ReferenceChange, boolean) in your case. If we can't properly copy the UUID, this is the most likely culprit. If there is a bug please track it on bugzilla with reproduction steps so that we can check from our side.
Laurent Goubet
Obeo
|
|
|
|
Re: New UUIDs for non-conflicting Addition changes after merge [message #1751765 is a reply to message #1751761] |
Fri, 13 January 2017 15:45 |
|
It sounds to me like you consider in your business rules that this attribute is the object's id... but that fact is not modelized (the attribute is not marked as being an id) and not xmi:id either.
This wouldn't be handled by EMF Compare itself since we're only applying "generic" rules in the implementation; rules that can be applied to all models. xmi:id (the ids that you can defined in an xmi resource) and id attributes (EAttributes that are considered as identifiers by EMF) are generic and handled, but what you're described doesn't look like it. What I believe should happen in your case is that EMF Compare should see the changes you make to your ids as regular attribute changes, that you thus have to accept as well in order to have the same id on both side. This will not be the case if your id is set as "derived" or is not part of the attributes compared (they're filtered out by the FeatureFilter).
Please tell me if the assumptions I make above are wrong, but if they are true, yes, I think what you've done through defining your own merger that will take care of copying the uuid is the best course of action.
Laurent Goubet
Obeo
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03368 seconds