Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 338394 - Failed to compare (NPE) local revision and distant SVN revision with 3.7M5
Summary: Failed to compare (NPE) local revision and distant SVN revision with 3.7M5
Status: CLOSED WORKSFORME
Alias: None
Product: EMFCompare
Classification: Modeling
Component: Team (show other bugs)
Version: unspecified   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: Kepler   Edit
Assignee: EMF Compare CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-28 06:09 EST by Mikaël Barbero CLA
Modified: 2013-01-23 07:25 EST (History)
2 users (show)

See Also:
mikael.barbero: indigo+

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Mikaël Barbero CLA 2011-02-28 06:09:24 EST 
Hi,

When I synchronize a versionned model ("selected resource only"), I get an NPE from EMF Compare.

The issue is that the SubversiveTeamHandler is assuming that Subversive is used if left and right resources are instances of ResourceElement.

It seems that it has changed in 3.7 (I only tested on 3.7M5). Now, left and right element of ICompareInput from Subversive are FileRevisionTypedElement (as CVS implementation of team API). Thus, the RevisionComparisonHandler is now being used to compare Subversive handled model files.

It should be OK, but the RevisionedURIConverterURIConverter#resolve() coming along with RevisionComparisonHandler throws NPE in this case. The retrieved IStorage from the base revision can not be used to find a workspace member by calling storage.getFullPath() because the returned IPath looks like more a to-be-displayed path than an usable one. For instance, it returns me something like that : "/test-uml-compare-svn/My.uml:5786 [username]"
Comment 1 Laurent Goubet CLA 2013-01-14 09:34:18 EST 
Cannot be reproduced with the latest 1.3 builds on either Juno or Indigo.