Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » [EMF Compare] Conflicting should be true, but is false
| [EMF Compare] Conflicting should be true, but is false [message #138210] |
Wed, 08 July 2009 15:15  |
Eclipse User |
|
|
|
Originally posted by: stephenmccants.yahoo.com
Hello,
I may not understand what "conflicting" really means, but I expect it to mean that there is a
conflict between two different changes such that they can't be merged.
Here is my scenario:
1) I have a server that has an EMF model.
2) A client gets a copy of the EMF model and renames the model (model.setName(String)).
3) The client tries to save the model back to the server, but the model on the server has already
changed (someone else renamed the model).
4) I get the two different models and use EMF compare to find the difference. It recognizes that
the name changed, but conflicting is false.
I also tried this using an ancestor that had the original name, but that didn't affect the results.
Am I thinking about this from the wrong direction?
Thanks for your help!
Sincerely,
Stephen McCants
|
|
|
| Re: [EMF Compare] Conflicting should be true, but is false [message #138223 is a reply to message #138210] |
Wed, 08 July 2009 20:08  |
| Eclipse User |
|
|
|
Originally posted by: stephenmccants.yahoo.com
Okay, I dug a little deeper (tracing through the Match and Diff code) and it seems that it doesn't
match the two objects that I give it, so it decides that the difference is an Addition and Remove
from the shared parent, instead of a Change.
I think this comes from a fundamental difference between what the Generic Match Engine expects a
name to mean (i.e. an unique identifier?) and what I'm using a name for (i.e. a human readable and
changable identifier). I think I'm going to try to extend the Generic Match Engine to match well
for my model. In my specific case I already know that the two objects I'm trying to compare are
matched, although I may do matching on the URI of the resource containing the objects (I have a one
object per URI constraint).
I do have one question though:
Is there (or should there be) a way to tell the Compare code not to follow references that belong to
other resources? Essentially, I'm looking to compare the objects that belong to one eResource
with the objects that belong to another eResource without comparing any objects in other eResources
that they may reference.
Thanks!
--Stephen
Stephen McCants wrote:
> Hello,
> I may not understand what "conflicting" really means, but I expect
> it to mean that there is a conflict between two different changes such
> that they can't be merged.
> Here is my scenario:
>
> 1) I have a server that has an EMF model.
> 2) A client gets a copy of the EMF model and renames the model
> (model.setName(String)).
> 3) The client tries to save the model back to the server, but the model
> on the server has already changed (someone else renamed the model).
> 4) I get the two different models and use EMF compare to find the
> difference. It recognizes that the name changed, but conflicting is false.
>
> I also tried this using an ancestor that had the original name, but that
> didn't affect the results.
> Am I thinking about this from the wrong direction?
> Thanks for your help!
>
> Sincerely,
> Stephen McCants
|
|
|
| Re: [EMF Compare] Conflicting should be true, but is false [message #138235 is a reply to message #138210] |
Thu, 09 July 2009 07:21 |
|
This is a multi-part message in MIME format.
--------------020001020309050802040900
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Hi Stephen,
Getting a conflicting change means that you made a change that actually
conflicts with what others did. If you rename your model from "model" to
"MyModel" and the other renamed it to the same, then your changes don't
actually conflict, they converge to the same value and as such EMF
Compare shouldn't even dectect a change.
If the common ancestor of your version and the version the other renamed
and commited has its name set to "model", he commited the model with
name "MyModel", and you try to rename the model to "Model.old", then a
conflict *should* be detected and it is a bug if not.
Is your case the first I mentionned here? Or the bug described
afterwards (hope not :p)?
Laurent Goubet
Obeo
Stephen McCants a
|
|
|
| Re: [EMF Compare] Conflicting should be true, but is false [message #138237 is a reply to message #138223] |
Thu, 09 July 2009 07:27 |
|
This is a multi-part message in MIME format.
--------------050606050108060605090806
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Stephen,
Sorry I answered the first post of this thread without noticing this one :(.
EMF Compare detecting an "addition" along with a "removal" instead of a
change indeed means that it doesn't manage to match the elements. This
can happen with small elements with not much to measure the distance
separating them (such as an element with only a "name" attribute). The
"name" attribute in EMF Compare indeed has a heavier weight than the
others when comparing, but it isn't seen as a unique identifier. Rather,
we expect the "name" to be "a human readable and changeable identifier",
as you expected. The side effect of this assumption being that we expect
it not to move too much between two identical elements and give it this
heavier weight.
There is no way to tell EMF Compare not to follow links to other
resources when comparing ... that may be a potential enhancement request :).
Laurent Goubet
Obeo
Stephen McCants a
|
|
|
| Re: [EMF Compare] Conflicting should be true, but is false [message #138356 is a reply to message #138235] |
Thu, 09 July 2009 14:45 |
| Eclipse User |
|
|
|
Originally posted by: stephenmccants.yahoo.com
Hi Laurent,
My case is the second mentioned, but it isn't a bug as I was not using an ancestor. Once I figured
that out and created an ancestor and used that, it correctly found the conflict. I'm still very
much on the learning curve for EMF Compare. Thank you for your help!
--Stephen
laurent Goubet wrote:
> Hi Stephen,
>
> Getting a conflicting change means that you made a change that actually
> conflicts with what others did. If you rename your model from "model" to
> "MyModel" and the other renamed it to the same, then your changes don't
> actually conflict, they converge to the same value and as such EMF
> Compare shouldn't even dectect a change.
>
> If the common ancestor of your version and the version the other renamed
> and commited has its name set to "model", he commited the model with
> name "MyModel", and you try to rename the model to "Model.old", then a
> conflict *should* be detected and it is a bug if not.
>
> Is your case the first I mentionned here? Or the bug described
> afterwards (hope not :p)?
>
> Laurent Goubet
> Obeo
>
> Stephen McCants a écrit :
>> Hello,
>> I may not understand what "conflicting" really means, but I expect
>> it to mean that there is a conflict between two different changes such
>> that they can't be merged.
>> Here is my scenario:
>>
>> 1) I have a server that has an EMF model.
>> 2) A client gets a copy of the EMF model and renames the model
>> (model.setName(String)).
>> 3) The client tries to save the model back to the server, but the
>> model on the server has already changed (someone else renamed the model).
>> 4) I get the two different models and use EMF compare to find the
>> difference. It recognizes that the name changed, but conflicting is
>> false.
>>
>> I also tried this using an ancestor that had the original name, but
>> that didn't affect the results.
>> Am I thinking about this from the wrong direction?
>> Thanks for your help!
>>
>> Sincerely,
>> Stephen McCants
>
|
|
|
| Re: [EMF Compare] Conflicting should be true, but is false [message #138400 is a reply to message #138356] |
Fri, 10 July 2009 22:31 |
| Eclipse User |
|
|
|
Originally posted by: stephenmccants.yahoo.com
Hi Laurent,
While it correctly found the conflict, the ConflictingDiffElement still returns false for
isConflicting(). That seems like a bug to me... Also, the UpdateAttribute element under the
ConflictingDiffElement returns false for isConflicting(). (For that matter so do the parent
DiffGroups).
I'm also generating a diff model that is much more complicated than I was expecting. Since there
are basically two objects in each model (left, right and ancestor each have two objects), only one
change, and the "top level" object (that is the object I passed into the Match and Diff engine, they
actually have a "parent"/"eContainer") is where the difference occurred, I would expect at most one
DiffGroup with the conflicting difference underneath. Even better would be no DiffGroup. Instead,
I have 3 DiffGroups:
<?xml version="1.0" encoding="ISO-8859-1"?>
<diff:DiffModel xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:diff="http://www.eclipse.org/emf/compare/diff/1.1">
<ownedElements xsi:type="diff:DiffGroup">
<subDiffElements xsi:type="diff:DiffGroup">
<subDiffElements xsi:type="diff:DiffGroup">
<subDiffElements xsi:type="diff:ConflictingDiffElement">
<subDiffElements xsi:type="diff:UpdateAttribute">
<attribute href=" http://www.ibm.com/xmlns/prod/hdwb/test/4.0#//TestResource/n ame"/>
<leftElement href=" https://localhost:9443/jazz/storage/com.ibm.hdwb.test/first# /"/>
<rightElement href=" https://localhost:9443/jazz/storage/com.ibm.hdwb.test/first# /"/>
</subDiffElements>
<leftParent href=" https://localhost:9443/jazz/storage/com.ibm.hdwb.test/first# /"/>
<rightParent href=" https://localhost:9443/jazz/storage/com.ibm.hdwb.test/first# /"/>
<originElement href=" https://localhost:9443/jazz/storage/com.ibm.hdwb.test/first# /"/>
</subDiffElements>
<rightParent href=" https://localhost:9443/jazz/storage/com.ibm.hdwb.test/first# /"/>
</subDiffElements>
<rightParent href=" https://localhost:9443/jazz/storage/com.ibm.hdwb.test/root#/"/>
</subDiffElements>
</ownedElements>
<leftRoots href=" https://localhost:9443/jazz/storage/com.ibm.hdwb.test/first# /"/>
<rightRoots href=" https://localhost:9443/jazz/storage/com.ibm.hdwb.test/first# /"/>
<ancestorRoots href=" https://localhost:9443/jazz/storage/com.ibm.hdwb.test/first# /"/>
</diff:DiffModel>
Is this the results you'd expect from so a comparison? Thanks!
--Stephen
Stephen McCants wrote:
> Hi Laurent,
> My case is the second mentioned, but it isn't a bug as I was not
> using an ancestor. Once I figured that out and created an ancestor and
> used that, it correctly found the conflict. I'm still very much on the
> learning curve for EMF Compare. Thank you for your help!
>
> --Stephen
>
> laurent Goubet wrote:
>> Hi Stephen,
>>
>> Getting a conflicting change means that you made a change that
>> actually conflicts with what others did. If you rename your model from
>> "model" to "MyModel" and the other renamed it to the same, then your
>> changes don't actually conflict, they converge to the same value and
>> as such EMF Compare shouldn't even dectect a change.
>>
>> If the common ancestor of your version and the version the other
>> renamed and commited has its name set to "model", he commited the
>> model with name "MyModel", and you try to rename the model to
>> "Model.old", then a conflict *should* be detected and it is a bug if not.
>>
>> Is your case the first I mentionned here? Or the bug described
>> afterwards (hope not :p)?
>>
>> Laurent Goubet
>> Obeo
>>
>> Stephen McCants a écrit :
>>> Hello,
>>> I may not understand what "conflicting" really means, but I
>>> expect it to mean that there is a conflict between two different
>>> changes such that they can't be merged.
>>> Here is my scenario:
>>>
>>> 1) I have a server that has an EMF model.
>>> 2) A client gets a copy of the EMF model and renames the model
>>> (model.setName(String)).
>>> 3) The client tries to save the model back to the server, but the
>>> model on the server has already changed (someone else renamed the
>>> model).
>>> 4) I get the two different models and use EMF compare to find the
>>> difference. It recognizes that the name changed, but conflicting is
>>> false.
>>>
>>> I also tried this using an ancestor that had the original name, but
>>> that didn't affect the results.
>>> Am I thinking about this from the wrong direction?
>>> Thanks for your help!
>>>
>>> Sincerely,
>>> Stephen McCants
>>
|
|
| |
| Re: [EMF Compare] Conflicting should be true, but is false [message #138645 is a reply to message #138597] |
Wed, 15 July 2009 16:48 |
| Eclipse User |
|
|
|
Originally posted by: stephenmccants.yahoo.com
Bug posted:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=283582
laurent Goubet wrote:
> Hi Stephen,
>
> Comments inlined below
>
> Stephen McCants a écrit :
>> Hi Laurent,
>> While it correctly found the conflict, the ConflictingDiffElement
>> still returns false for isConflicting(). That seems like a bug to
>
> This is an oversight ... and indeed a bug. It should be fixed in the
> next build, don't hesitate to raise a bug so it can be verified though.
>
>> me... Also, the UpdateAttribute element under the
>> ConflictingDiffElement returns false for isConflicting(). (For that
>> matter so do the parent DiffGroups).
>
> The parent DiffGroups aren't conflicting, as they're in the model to
> reproduce the original hierarchy. The UpdateAttribute contained in the
> ConflictingDiffElement should have its "isConflicting" method return
> true though. Take note that the _method_ should return true, but the
> _attribute_ "conflicting" will be "false" until the method is called. If
> you are indeed calling the "isConflicting" method, then it is a bug :(.
>
>> I'm also generating a diff model that is much more complicated
>> than I was expecting. Since there are basically two objects in each
>> model (left, right and ancestor each have two objects), only one
>> change, and the "top level" object (that is the object I passed into
>> the Match and Diff engine, they actually have a "parent"/"eContainer")
>> is where the difference occurred, I would expect at most one DiffGroup
>> with the conflicting difference underneath. Even better would be no
>> DiffGroup. Instead, I have 3 DiffGroups:
>
> EMF Compare uses DiffGroups to reproduce the hierarchy of its input
> models. If your model looks as :
> package1
> |----package2
> |----package3
> |----ClassA
>
> and your conflicting change is in "ClassA", the resulting DiffModel will
> contain a DiffGroup for package1 containing a DiffGroup for package2
> containing a DiffGroup for package3 containing the conflicting change.
>
>>
>> <?xml version="1.0" encoding="ISO-8859-1"?>
>> <diff:DiffModel xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xmlns:diff="http://www.eclipse.org/emf/compare/diff/1.1">
>> <ownedElements xsi:type="diff:DiffGroup">
>> <subDiffElements xsi:type="diff:DiffGroup">
>> <subDiffElements xsi:type="diff:DiffGroup">
>> <subDiffElements xsi:type="diff:ConflictingDiffElement">
>> <subDiffElements xsi:type="diff:UpdateAttribute">
>> <attribute
>> href=" http://www.ibm.com/xmlns/prod/hdwb/test/4.0#//TestResource/n ame"/>
>> <leftElement
>> href=" https://localhost:9443/jazz/storage/com.ibm.hdwb.test/first# /"/>
>> <rightElement
>> href=" https://localhost:9443/jazz/storage/com.ibm.hdwb.test/first# /"/>
>> </subDiffElements>
>> <leftParent
>> href=" https://localhost:9443/jazz/storage/com.ibm.hdwb.test/first# /"/>
>> <rightParent
>> href=" https://localhost:9443/jazz/storage/com.ibm.hdwb.test/first# /"/>
>> <originElement
>> href=" https://localhost:9443/jazz/storage/com.ibm.hdwb.test/first# /"/>
>> </subDiffElements>
>> <rightParent
>> href=" https://localhost:9443/jazz/storage/com.ibm.hdwb.test/first# /"/>
>> </subDiffElements>
>> <rightParent
>> href=" https://localhost:9443/jazz/storage/com.ibm.hdwb.test/root#/"/>
>> </subDiffElements>
>> </ownedElements>
>> <leftRoots
>> href=" https://localhost:9443/jazz/storage/com.ibm.hdwb.test/first# /"/>
>> <rightRoots
>> href=" https://localhost:9443/jazz/storage/com.ibm.hdwb.test/first# /"/>
>> <ancestorRoots
>> href=" https://localhost:9443/jazz/storage/com.ibm.hdwb.test/first# /"/>
>> </diff:DiffModel>
>>
>> Is this the results you'd expect from so a comparison? Thanks!
>>
>> --Stephen
>>
>
> Regards,
>
> Laurent Goubet
> Obeo
>
>> Stephen McCants wrote:
>>> Hi Laurent,
>>> My case is the second mentioned, but it isn't a bug as I was not
>>> using an ancestor. Once I figured that out and created an ancestor
>>> and used that, it correctly found the conflict. I'm still very much
>>> on the learning curve for EMF Compare. Thank you for your help!
>>>
>>> --Stephen
>>>
>>> laurent Goubet wrote:
>>>> Hi Stephen,
>>>>
>>>> Getting a conflicting change means that you made a change that
>>>> actually conflicts with what others did. If you rename your model
>>>> from "model" to "MyModel" and the other renamed it to the same, then
>>>> your changes don't actually conflict, they converge to the same
>>>> value and as such EMF Compare shouldn't even dectect a change.
>>>>
>>>> If the common ancestor of your version and the version the other
>>>> renamed and commited has its name set to "model", he commited the
>>>> model with name "MyModel", and you try to rename the model to
>>>> "Model.old", then a conflict *should* be detected and it is a bug if
>>>> not.
>>>>
>>>> Is your case the first I mentionned here? Or the bug described
>>>> afterwards (hope not :p)?
>>>>
>>>> Laurent Goubet
>>>> Obeo
>>>>
>>>> Stephen McCants a écrit :
>>>>> Hello,
>>>>> I may not understand what "conflicting" really means, but I
>>>>> expect it to mean that there is a conflict between two different
>>>>> changes such that they can't be merged.
>>>>> Here is my scenario:
>>>>>
>>>>> 1) I have a server that has an EMF model.
>>>>> 2) A client gets a copy of the EMF model and renames the model
>>>>> (model.setName(String)).
>>>>> 3) The client tries to save the model back to the server, but the
>>>>> model on the server has already changed (someone else renamed the
>>>>> model).
>>>>> 4) I get the two different models and use EMF compare to find the
>>>>> difference. It recognizes that the name changed, but conflicting
>>>>> is false.
>>>>>
>>>>> I also tried this using an ancestor that had the original name, but
>>>>> that didn't affect the results.
>>>>> Am I thinking about this from the wrong direction?
>>>>> Thanks for your help!
>>>>>
>>>>> Sincerely,
>>>>> Stephen McCants
>>>>
>
|
|
|
| Re: [EMF Compare] Conflicting should be true, but is false [message #621106 is a reply to message #138210] |
Wed, 08 July 2009 20:08 |
 Stephen McCants
Messages: 92
Registered: July 2009 |
Member |
|
|
Okay, I dug a little deeper (tracing through the Match and Diff code) and it seems that it doesn't
match the two objects that I give it, so it decides that the difference is an Addition and Remove
from the shared parent, instead of a Change.
I think this comes from a fundamental difference between what the Generic Match Engine expects a
name to mean (i.e. an unique identifier?) and what I'm using a name for (i.e. a human readable and
changable identifier). I think I'm going to try to extend the Generic Match Engine to match well
for my model. In my specific case I already know that the two objects I'm trying to compare are
matched, although I may do matching on the URI of the resource containing the objects (I have a one
object per URI constraint).
I do have one question though:
Is there (or should there be) a way to tell the Compare code not to follow references that belong to
other resources? Essentially, I'm looking to compare the objects that belong to one eResource
with the objects that belong to another eResource without comparing any objects in other eResources
that they may reference.
Thanks!
--Stephen
Stephen McCants wrote:
> Hello,
> I may not understand what "conflicting" really means, but I expect
> it to mean that there is a conflict between two different changes such
> that they can't be merged.
> Here is my scenario:
>
> 1) I have a server that has an EMF model.
> 2) A client gets a copy of the EMF model and renames the model
> (model.setName(String)).
> 3) The client tries to save the model back to the server, but the model
> on the server has already changed (someone else renamed the model).
> 4) I get the two different models and use EMF compare to find the
> difference. It recognizes that the name changed, but conflicting is false.
>
> I also tried this using an ancestor that had the original name, but that
> didn't affect the results.
> Am I thinking about this from the wrong direction?
> Thanks for your help!
>
> Sincerely,
> Stephen McCants
|
|
|
| Re: [EMF Compare] Conflicting should be true, but is false [message #621109 is a reply to message #138210] |
Thu, 09 July 2009 07:21 |
|
This is a multi-part message in MIME format.
--------------020001020309050802040900
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Hi Stephen,
Getting a conflicting change means that you made a change that actually
conflicts with what others did. If you rename your model from "model" to
"MyModel" and the other renamed it to the same, then your changes don't
actually conflict, they converge to the same value and as such EMF
Compare shouldn't even dectect a change.
If the common ancestor of your version and the version the other renamed
and commited has its name set to "model", he commited the model with
name "MyModel", and you try to rename the model to "Model.old", then a
conflict *should* be detected and it is a bug if not.
Is your case the first I mentionned here? Or the bug described
afterwards (hope not :p)?
Laurent Goubet
Obeo
Stephen McCants a
|
|
|
| Re: [EMF Compare] Conflicting should be true, but is false [message #621110 is a reply to message #138223] |
Thu, 09 July 2009 07:27 |
|
This is a multi-part message in MIME format.
--------------050606050108060605090806
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Stephen,
Sorry I answered the first post of this thread without noticing this one :(.
EMF Compare detecting an "addition" along with a "removal" instead of a
change indeed means that it doesn't manage to match the elements. This
can happen with small elements with not much to measure the distance
separating them (such as an element with only a "name" attribute). The
"name" attribute in EMF Compare indeed has a heavier weight than the
others when comparing, but it isn't seen as a unique identifier. Rather,
we expect the "name" to be "a human readable and changeable identifier",
as you expected. The side effect of this assumption being that we expect
it not to move too much between two identical elements and give it this
heavier weight.
There is no way to tell EMF Compare not to follow links to other
resources when comparing ... that may be a potential enhancement request :).
Laurent Goubet
Obeo
Stephen McCants a
|
|
|
| Re: [EMF Compare] Conflicting should be true, but is false [message #621113 is a reply to message #138235] |
Thu, 09 July 2009 14:45 |
Stephen McCants
Messages: 92
Registered: July 2009 |
Member |
|
|
Hi Laurent,
My case is the second mentioned, but it isn't a bug as I was not using an ancestor. Once I figured
that out and created an ancestor and used that, it correctly found the conflict. I'm still very
much on the learning curve for EMF Compare. Thank you for your help!
--Stephen
laurent Goubet wrote:
> Hi Stephen,
>
> Getting a conflicting change means that you made a change that actually
> conflicts with what others did. If you rename your model from "model" to
> "MyModel" and the other renamed it to the same, then your changes don't
> actually conflict, they converge to the same value and as such EMF
> Compare shouldn't even dectect a change.
>
> If the common ancestor of your version and the version the other renamed
> and commited has its name set to "model", he commited the model with
> name "MyModel", and you try to rename the model to "Model.old", then a
> conflict *should* be detected and it is a bug if not.
>
> Is your case the first I mentionned here? Or the bug described
> afterwards (hope not :p)?
>
> Laurent Goubet
> Obeo
>
> Stephen McCants a écrit :
>> Hello,
>> I may not understand what "conflicting" really means, but I expect
>> it to mean that there is a conflict between two different changes such
>> that they can't be merged.
>> Here is my scenario:
>>
>> 1) I have a server that has an EMF model.
>> 2) A client gets a copy of the EMF model and renames the model
>> (model.setName(String)).
>> 3) The client tries to save the model back to the server, but the
>> model on the server has already changed (someone else renamed the model).
>> 4) I get the two different models and use EMF compare to find the
>> difference. It recognizes that the name changed, but conflicting is
>> false.
>>
>> I also tried this using an ancestor that had the original name, but
>> that didn't affect the results.
>> Am I thinking about this from the wrong direction?
>> Thanks for your help!
>>
>> Sincerely,
>> Stephen McCants
>
|
|
|
| Re: [EMF Compare] Conflicting should be true, but is false [message #621116 is a reply to message #138356] |
Fri, 10 July 2009 22:31 |
Stephen McCants
Messages: 92
Registered: July 2009 |
Member |
|
|
Hi Laurent,
While it correctly found the conflict, the ConflictingDiffElement still returns false for
isConflicting(). That seems like a bug to me... Also, the UpdateAttribute element under the
ConflictingDiffElement returns false for isConflicting(). (For that matter so do the parent
DiffGroups).
I'm also generating a diff model that is much more complicated than I was expecting. Since there
are basically two objects in each model (left, right and ancestor each have two objects), only one
change, and the "top level" object (that is the object I passed into the Match and Diff engine, they
actually have a "parent"/"eContainer") is where the difference occurred, I would expect at most one
DiffGroup with the conflicting difference underneath. Even better would be no DiffGroup. Instead,
I have 3 DiffGroups:
<?xml version="1.0" encoding="ISO-8859-1"?>
<diff:DiffModel xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:diff="http://www.eclipse.org/emf/compare/diff/1.1">
<ownedElements xsi:type="diff:DiffGroup">
<subDiffElements xsi:type="diff:DiffGroup">
<subDiffElements xsi:type="diff:DiffGroup">
<subDiffElements xsi:type="diff:ConflictingDiffElement">
<subDiffElements xsi:type="diff:UpdateAttribute">
<attribute href=" http://www.ibm.com/xmlns/prod/hdwb/test/4.0#//TestResource/n ame"/>
<leftElement href=" https://localhost:9443/jazz/storage/com.ibm.hdwb.test/first# /"/>
<rightElement href=" https://localhost:9443/jazz/storage/com.ibm.hdwb.test/first# /"/>
</subDiffElements>
<leftParent href=" https://localhost:9443/jazz/storage/com.ibm.hdwb.test/first# /"/>
<rightParent href=" https://localhost:9443/jazz/storage/com.ibm.hdwb.test/first# /"/>
<originElement href=" https://localhost:9443/jazz/storage/com.ibm.hdwb.test/first# /"/>
</subDiffElements>
<rightParent href=" https://localhost:9443/jazz/storage/com.ibm.hdwb.test/first# /"/>
</subDiffElements>
<rightParent href=" https://localhost:9443/jazz/storage/com.ibm.hdwb.test/root#/"/>
</subDiffElements>
</ownedElements>
<leftRoots href=" https://localhost:9443/jazz/storage/com.ibm.hdwb.test/first# /"/>
<rightRoots href=" https://localhost:9443/jazz/storage/com.ibm.hdwb.test/first# /"/>
<ancestorRoots href=" https://localhost:9443/jazz/storage/com.ibm.hdwb.test/first# /"/>
</diff:DiffModel>
Is this the results you'd expect from so a comparison? Thanks!
--Stephen
Stephen McCants wrote:
> Hi Laurent,
> My case is the second mentioned, but it isn't a bug as I was not
> using an ancestor. Once I figured that out and created an ancestor and
> used that, it correctly found the conflict. I'm still very much on the
> learning curve for EMF Compare. Thank you for your help!
>
> --Stephen
>
> laurent Goubet wrote:
>> Hi Stephen,
>>
>> Getting a conflicting change means that you made a change that
>> actually conflicts with what others did. If you rename your model from
>> "model" to "MyModel" and the other renamed it to the same, then your
>> changes don't actually conflict, they converge to the same value and
>> as such EMF Compare shouldn't even dectect a change.
>>
>> If the common ancestor of your version and the version the other
>> renamed and commited has its name set to "model", he commited the
>> model with name "MyModel", and you try to rename the model to
>> "Model.old", then a conflict *should* be detected and it is a bug if not.
>>
>> Is your case the first I mentionned here? Or the bug described
>> afterwards (hope not :p)?
>>
>> Laurent Goubet
>> Obeo
>>
>> Stephen McCants a écrit :
>>> Hello,
>>> I may not understand what "conflicting" really means, but I
>>> expect it to mean that there is a conflict between two different
>>> changes such that they can't be merged.
>>> Here is my scenario:
>>>
>>> 1) I have a server that has an EMF model.
>>> 2) A client gets a copy of the EMF model and renames the model
>>> (model.setName(String)).
>>> 3) The client tries to save the model back to the server, but the
>>> model on the server has already changed (someone else renamed the
>>> model).
>>> 4) I get the two different models and use EMF compare to find the
>>> difference. It recognizes that the name changed, but conflicting is
>>> false.
>>>
>>> I also tried this using an ancestor that had the original name, but
>>> that didn't affect the results.
>>> Am I thinking about this from the wrong direction?
>>> Thanks for your help!
>>>
>>> Sincerely,
>>> Stephen McCants
>>
|
|
| |
| Re: [EMF Compare] Conflicting should be true, but is false [message #621136 is a reply to message #138597] |
Wed, 15 July 2009 16:48 |
Stephen McCants
Messages: 92
Registered: July 2009 |
Member |
|
|
Bug posted:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=283582
laurent Goubet wrote:
> Hi Stephen,
>
> Comments inlined below
>
> Stephen McCants a écrit :
>> Hi Laurent,
>> While it correctly found the conflict, the ConflictingDiffElement
>> still returns false for isConflicting(). That seems like a bug to
>
> This is an oversight ... and indeed a bug. It should be fixed in the
> next build, don't hesitate to raise a bug so it can be verified though.
>
>> me... Also, the UpdateAttribute element under the
>> ConflictingDiffElement returns false for isConflicting(). (For that
>> matter so do the parent DiffGroups).
>
> The parent DiffGroups aren't conflicting, as they're in the model to
> reproduce the original hierarchy. The UpdateAttribute contained in the
> ConflictingDiffElement should have its "isConflicting" method return
> true though. Take note that the _method_ should return true, but the
> _attribute_ "conflicting" will be "false" until the method is called. If
> you are indeed calling the "isConflicting" method, then it is a bug :(.
>
>> I'm also generating a diff model that is much more complicated
>> than I was expecting. Since there are basically two objects in each
>> model (left, right and ancestor each have two objects), only one
>> change, and the "top level" object (that is the object I passed into
>> the Match and Diff engine, they actually have a "parent"/"eContainer")
>> is where the difference occurred, I would expect at most one DiffGroup
>> with the conflicting difference underneath. Even better would be no
>> DiffGroup. Instead, I have 3 DiffGroups:
>
> EMF Compare uses DiffGroups to reproduce the hierarchy of its input
> models. If your model looks as :
> package1
> |----package2
> |----package3
> |----ClassA
>
> and your conflicting change is in "ClassA", the resulting DiffModel will
> contain a DiffGroup for package1 containing a DiffGroup for package2
> containing a DiffGroup for package3 containing the conflicting change.
>
>>
>> <?xml version="1.0" encoding="ISO-8859-1"?>
>> <diff:DiffModel xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xmlns:diff="http://www.eclipse.org/emf/compare/diff/1.1">
>> <ownedElements xsi:type="diff:DiffGroup">
>> <subDiffElements xsi:type="diff:DiffGroup">
>> <subDiffElements xsi:type="diff:DiffGroup">
>> <subDiffElements xsi:type="diff:ConflictingDiffElement">
>> <subDiffElements xsi:type="diff:UpdateAttribute">
>> <attribute
>> href=" http://www.ibm.com/xmlns/prod/hdwb/test/4.0#//TestResource/n ame"/>
>> <leftElement
>> href=" https://localhost:9443/jazz/storage/com.ibm.hdwb.test/first# /"/>
>> <rightElement
>> href=" https://localhost:9443/jazz/storage/com.ibm.hdwb.test/first# /"/>
>> </subDiffElements>
>> <leftParent
>> href=" https://localhost:9443/jazz/storage/com.ibm.hdwb.test/first# /"/>
>> <rightParent
>> href=" https://localhost:9443/jazz/storage/com.ibm.hdwb.test/first# /"/>
>> <originElement
>> href=" https://localhost:9443/jazz/storage/com.ibm.hdwb.test/first# /"/>
>> </subDiffElements>
>> <rightParent
>> href=" https://localhost:9443/jazz/storage/com.ibm.hdwb.test/first# /"/>
>> </subDiffElements>
>> <rightParent
>> href=" https://localhost:9443/jazz/storage/com.ibm.hdwb.test/root#/"/>
>> </subDiffElements>
>> </ownedElements>
>> <leftRoots
>> href=" https://localhost:9443/jazz/storage/com.ibm.hdwb.test/first# /"/>
>> <rightRoots
>> href=" https://localhost:9443/jazz/storage/com.ibm.hdwb.test/first# /"/>
>> <ancestorRoots
>> href=" https://localhost:9443/jazz/storage/com.ibm.hdwb.test/first# /"/>
>> </diff:DiffModel>
>>
>> Is this the results you'd expect from so a comparison? Thanks!
>>
>> --Stephen
>>
>
> Regards,
>
> Laurent Goubet
> Obeo
>
>> Stephen McCants wrote:
>>> Hi Laurent,
>>> My case is the second mentioned, but it isn't a bug as I was not
>>> using an ancestor. Once I figured that out and created an ancestor
>>> and used that, it correctly found the conflict. I'm still very much
>>> on the learning curve for EMF Compare. Thank you for your help!
>>>
>>> --Stephen
>>>
>>> laurent Goubet wrote:
>>>> Hi Stephen,
>>>>
>>>> Getting a conflicting change means that you made a change that
>>>> actually conflicts with what others did. If you rename your model
>>>> from "model" to "MyModel" and the other renamed it to the same, then
>>>> your changes don't actually conflict, they converge to the same
>>>> value and as such EMF Compare shouldn't even dectect a change.
>>>>
>>>> If the common ancestor of your version and the version the other
>>>> renamed and commited has its name set to "model", he commited the
>>>> model with name "MyModel", and you try to rename the model to
>>>> "Model.old", then a conflict *should* be detected and it is a bug if
>>>> not.
>>>>
>>>> Is your case the first I mentionned here? Or the bug described
>>>> afterwards (hope not :p)?
>>>>
>>>> Laurent Goubet
>>>> Obeo
>>>>
>>>> Stephen McCants a écrit :
>>>>> Hello,
>>>>> I may not understand what "conflicting" really means, but I
>>>>> expect it to mean that there is a conflict between two different
>>>>> changes such that they can't be merged.
>>>>> Here is my scenario:
>>>>>
>>>>> 1) I have a server that has an EMF model.
>>>>> 2) A client gets a copy of the EMF model and renames the model
>>>>> (model.setName(String)).
>>>>> 3) The client tries to save the model back to the server, but the
>>>>> model on the server has already changed (someone else renamed the
>>>>> model).
>>>>> 4) I get the two different models and use EMF compare to find the
>>>>> difference. It recognizes that the name changed, but conflicting
>>>>> is false.
>>>>>
>>>>> I also tried this using an ancestor that had the original name, but
>>>>> that didn't affect the results.
>>>>> Am I thinking about this from the wrong direction?
>>>>> Thanks for your help!
>>>>>
>>>>> Sincerely,
>>>>> Stephen McCants
>>>>
>
|
|
|
Goto Forum:
Current Time: Fri Apr 26 08:54:51 GMT 2024
Powered by FUDForum. Page generated in 0.03495 seconds |
] 
Search
Help
Register
Login
Home
