Re: [EMF Compare] Move of an element [message #498732] |
Wed, 18 November 2009 12:48 |
|
This is a multi-part message in MIME format.
--------------010206090205010600070903
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Hi Andreas,
Please use the EMF forum for questions on EMF Compare, I've added it to
the To: list of this reply.
This is bug 263200 https://bugs.eclipse.org/bugs/show_bug.cgi?id=263200
we haven't looked into yet.
The jist of it is that we only detect top-level changes for additions
and deletions : we do not go "inside" the added/deleted element to see
if other differences such as move can be detected there.
Laurent Goubet
Obeo
Andreas Scharf wrote:
> Hi,
>
> I have a question concerning the comparison between UML files. I have
> the following example models:
>
> ModelA
> |- Foo
> |- +someAttribute:Integer
>
> ModelB
> |- Foo
> |- Bar
> |- +someAttribute:Integer
>
> The scenario was as follows: I created a new class in ModelB 'Bar' and
> moved the attribute 'someAttribute:Integer' from 'Foo' to 'Bar'.
>
> What I was expecting is the ADDITION of 'BAR' and a 'MOVE' of
> 'someAttribute:Integer' from 'Foo' to 'Bar' but what I get is: ADDITION
> of 'BAR' and DELETE of 'someAttribute:Integer'.
>
> I ensured that the XMI IDs are the same and the OPTION_IGNORE_XMI_ID is
> turned off to give the match engine the chance to do the match.
>
> Am I doing anything wrong or is this behavior a bug?
>
> Kind regards,
> Andreas
--------------010206090205010600070903
Content-Type: text/x-vcard; charset=utf-8;
name="laurent_goubet.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="laurent_goubet.vcf"
begin:vcard
fn:Laurent Goubet
n:Goubet;Laurent
org:<a href="http://www.obeo.fr">Obeo</a>
email;internet:laurent.goubet@obeo.fr
url:http://www.obeo.fr
version:2.1
end:vcard
--------------010206090205010600070903--
|
|
|
Re: [EMF Compare] Move of an element [message #498738 is a reply to message #498732] |
Wed, 18 November 2009 13:05 |
Eclipse User |
|
|
|
Originally posted by: mail.andreasscharf.com
Hi Laurent,
thanks for moving the topic and pointing me to the bug. Any hints to
(fast) workaround this issue?
Andreas
Laurent Goubet schrieb:
> Hi Andreas,
>
> Please use the EMF forum for questions on EMF Compare, I've added it to
> the To: list of this reply.
>
> This is bug 263200 https://bugs.eclipse.org/bugs/show_bug.cgi?id=263200
> we haven't looked into yet.
>
> The jist of it is that we only detect top-level changes for additions
> and deletions : we do not go "inside" the added/deleted element to see
> if other differences such as move can be detected there.
>
> Laurent Goubet
> Obeo
>
> Andreas Scharf wrote:
>> Hi,
>>
>> I have a question concerning the comparison between UML files. I have
>> the following example models:
>>
>> ModelA
>> |- Foo
>> |- +someAttribute:Integer
>>
>> ModelB
>> |- Foo
>> |- Bar
>> |- +someAttribute:Integer
>>
>> The scenario was as follows: I created a new class in ModelB 'Bar' and
>> moved the attribute 'someAttribute:Integer' from 'Foo' to 'Bar'.
>>
>> What I was expecting is the ADDITION of 'BAR' and a 'MOVE' of
>> 'someAttribute:Integer' from 'Foo' to 'Bar' but what I get is:
>> ADDITION of 'BAR' and DELETE of 'someAttribute:Integer'.
>>
>> I ensured that the XMI IDs are the same and the OPTION_IGNORE_XMI_ID
>> is turned off to give the match engine the chance to do the match.
>>
>> Am I doing anything wrong or is this behavior a bug?
>>
>> Kind regards,
>> Andreas
>
|
|
|
Re: [EMF Compare] Move of an element [message #498801 is a reply to message #498738] |
Wed, 18 November 2009 16:34 |
|
This is a multi-part message in MIME format.
--------------020308050609090304000900
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Andreas,
We had nothing planned for this, I then went ahead to try and find at
least *when* we would be able to implement this ... and I ended up
thinking that it's pretty much impossible to /generically/ determine
that a given unmatched element is really a move. See my comment on the
bug, we can continue discussing the issue directly there if it's ok for you.
Laurent Goubet
Obeo
Andreas Scharf wrote:
> Hi Laurent,
>
> thanks for moving the topic and pointing me to the bug. Any hints to
> (fast) workaround this issue?
>
> Andreas
>
> Laurent Goubet schrieb:
>> Hi Andreas,
>>
>> Please use the EMF forum for questions on EMF Compare, I've added it
>> to the To: list of this reply.
>>
>> This is bug 263200
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=263200 we haven't looked
>> into yet.
>>
>> The jist of it is that we only detect top-level changes for additions
>> and deletions : we do not go "inside" the added/deleted element to see
>> if other differences such as move can be detected there.
>>
>> Laurent Goubet
>> Obeo
>>
>> Andreas Scharf wrote:
>>> Hi,
>>>
>>> I have a question concerning the comparison between UML files. I have
>>> the following example models:
>>>
>>> ModelA
>>> |- Foo
>>> |- +someAttribute:Integer
>>>
>>> ModelB
>>> |- Foo
>>> |- Bar
>>> |- +someAttribute:Integer
>>>
>>> The scenario was as follows: I created a new class in ModelB 'Bar'
>>> and moved the attribute 'someAttribute:Integer' from 'Foo' to 'Bar'.
>>>
>>> What I was expecting is the ADDITION of 'BAR' and a 'MOVE' of
>>> 'someAttribute:Integer' from 'Foo' to 'Bar' but what I get is:
>>> ADDITION of 'BAR' and DELETE of 'someAttribute:Integer'.
>>>
>>> I ensured that the XMI IDs are the same and the OPTION_IGNORE_XMI_ID
>>> is turned off to give the match engine the chance to do the match.
>>>
>>> Am I doing anything wrong or is this behavior a bug?
>>>
>>> Kind regards,
>>> Andreas
>>
--------------020308050609090304000900
Content-Type: text/x-vcard; charset=utf-8;
name="laurent_goubet.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="laurent_goubet.vcf"
begin:vcard
fn:Laurent Goubet
n:Goubet;Laurent
org:<a href="http://www.obeo.fr">Obeo</a>
email;internet:laurent.goubet@obeo.fr
url:http://www.obeo.fr
version:2.1
end:vcard
--------------020308050609090304000900--
|
|
|
Powered by
FUDForum. Page generated in 0.23998 seconds