Bugzilla – Full Text Bug Listing
| Summary: | Failed to compare (NPE) local revision and distant SVN revision with 3.7M5 | ||
|---|---|---|---|
| Product: | [Modeling] EMFCompare | Reporter: | Mikaël Barbero <mikael.barbero> |
| Component: | Team | Assignee: | EMF Compare <emf.compare-inbox> |
| Status: | CLOSED WORKSFORME | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | laurent.goubet, mikael.barbero |
| Version: | unspecified | Flags: | mikael.barbero:
indigo+
|
| Target Milestone: | Kepler | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
Cannot be reproduced with the latest 1.3 builds on either Juno or Indigo. |
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]"