Eclipse Community Forums: EMF "Technology" (Ecore Tools, EMFatic, etc) » [EMF Compare] Use EMF Compare to resolve conflicts

Help

Home

Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » [EMF Compare] Use EMF Compare to resolve conflicts

Show: Today's Messages :: Show Polls :: Message Navigator

[EMF Compare] Use EMF Compare to resolve conflicts [message #130928]

Mon, 24 November 2008 13:54

Tor Neple

Messages: 57
Registered: July 2009

Member

Hello

I have been experimenting using EMF Compare with subversion and the
Subclipse Eclipse integration. I find it works well for doing the
"compare with..." function. However when resolving conflicts it seems as
if the EMF compare functionality is not used at all. When I choose "edit
conflicts" from the team menu the conflict editor showing the text
representation of the models is shown.

That was not the best of explanations...this is the scenario:
User 1 creates a model with one class having one attribute and comitts
it to subversion
User 2 checks out the model and adds one more attribute to the class
User 1 adds one more attribute to the class
User 1 commits
User 2 attemts to commit, but subversion informs of the conflict
User 2 performs update and gets a proposed merge file of the model (in
addition to the .mine and .rXXX files
User 2 invokes the "edit conflicts" menu option.

In this case I would have thought that the EMF compare/merge ui should
be invoked? Is there any way of invoking the EMF functionality manually?
The functionality in the tooling is sufficient to do the merge I think.
This may just be me using the tools wrong, but I do update before
committ I guess I have the same challenge.

On a separate, but related, thought the changes described above may not
actually be conflicting changes, depending on the level of granularity.
(I guess subversion sees that the two files are not equal, and then
thinks it is a conflict.) The two attributes for the class are both
valid, but nevertheless subversion chooses to say that there is a
conflict. Is this something that lies in the subversion "server" or is
it something that is handled by the Team provider (in this case
subclipse and EMF Compare)?

Anyways, thanks for all of the work, I think being able to use sensible
diff/merge is essential for the MDE vision.

Regards

Tor

Report message to a moderator

Re: [EMF Compare] Use EMF Compare to resolve conflicts [message #130941 is a reply to message #130928]

Mon, 24 November 2008 14:29

Laurent Goubet

Messages: 1902
Registered: July 2009

Senior Member

This is a multi-part message in MIME format.
--------------090900000900020503010304
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Hi Tor,

I have to admit I never tested this action since I though it would call
EMF Compare as long as the files were registered for comparison with it.
If it is not ... well it is a bug :). Could you raise a bugzilla for
this issue?

For now I used the synchronized view and reviewed/merged the conflicts
through the comparison UI instead of updating and editing through the
"edit conflicts" action.

A second issue you've raised is the fact that subversion sees conflicts
where EMF Compare does not :S. Can you track a second bugzilla for this?
changes are it is a problem deeper in the compare framework yet I'll
look into it a bit more ASAP.

Thanks for your feedback,

Laurent Goubet
Obeo

Tor Neple a

Report message to a moderator

Re: [EMF Compare] Use EMF Compare to resolve conflicts [message #482302 is a reply to message #130941]

Wed, 26 August 2009 07:44

Sorin Fagateanu

Messages: 46
Registered: July 2009

Member

I have similar problems, not being able to edit conflicts because EMF Compare is not called.
I have put some breakpoints and I see that the files with extension .rXXX are not correctly dispatched to xml content type so Emf Compare Viewer to be called.

I see the discussion is dated from november 2008 and I am curious if any advances had been made with this bug.
If not I would like some ideas how this bug could be resolved.

Thanks in advance!
Sorin

Report message to a moderator

Re: [EMF Compare] Use EMF Compare to resolve conflicts [message #482667 is a reply to message #482302]

Thu, 27 August 2009 13:22

Laurent Goubet

Messages: 1902
Registered: July 2009

Senior Member

This is a multi-part message in MIME format.
--------------000307020807080904040107
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Sorin,

When reviving old threads, please leave the old messages below yours so
that we can understand what you're talking about : I use thunderbird and
delete all messages more than two monthes old. Going on the newsportal
and searching through google to find the message is quite bothersome.

In any case, no bug has ever been raised for this issue and as I
mentionned in my answer "I never tested this action since I though it
would call EMF Compare as long as the files were registered for
comparison with it". In fact, I absolutely never use this menu item and
will never notice bugs on it :p.

Laurent Goubet
Obeo

Sorin Fagateanu a écrit :
> I have similar problems, not being able to edit conflicts because EMF
> Compare is not called. I have put some breakpoints and I see that the
> files with extension .rXXX are not correctly dispatched to xml content
> type so Emf Compare Viewer to be called.
>
> I see the discussion is dated from november 2008 and I am curious if any
> advances had been made with this bug.
> If not I would like some ideas how this bug could be resolved.
>
> Thanks in advance!
> Sorin
>
>

--------------000307020807080904040107
Content-Type: text/x-vcard; charset=utf-8;
name="laurent_goubet.vcf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="laurent_goubet.vcf"

YmVnaW46dmNhcmQNCmZuOkxhdXJlbnQgR291YmV0DQpuOkdvdWJldDtMYXVy ZW50DQpvcmc6
PGEgaHJlZj0iaHR0cDovL3d3dy5vYmVvLmZyLyI+T2JlbzwvYT4NCmVtYWls O2ludGVybmV0
OmxhdXJlbnQuZ291YmV0QG9iZW8uZnINCnVybDpodHRwOi8vd3d3Lm9iZW8u ZnINCnZlcnNp
b246Mi4xDQplbmQ6dmNhcmQNCg0K
--------------000307020807080904040107--

Report message to a moderator