Bugzilla – Full Text Bug Listing
| Summary: | EMF Compare cannot be used on SVN repositories | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Modeling] EMFCompare | Reporter: | Laurent Goubet <laurent.goubet> | ||||
| Component: | Team | Assignee: | EMF Compare <emf.compare-inbox> | ||||
| Status: | CLOSED FIXED | QA Contact: | |||||
| Severity: | major | ||||||
| Priority: | P3 | CC: | Andreas.Muelder, borice.arcier, gailmjak, klaas.gadeyne, mikael.barbero, nelson.yap, preetam.palwe, s.holzknecht | ||||
| Version: | 2.1.0 | Keywords: | helpwanted | ||||
| Target Milestone: | Mars | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Laurent Goubet
Most likely needs API changes. Make sure this is planned before the M6 API freeze. *** Bug 405893 has been marked as a duplicate of this bug. *** Is this the logical net result when trying anyway? An internal error occurred during: "Compute Model Differences". java.lang.IllegalArgumentException: Path must include project and resource name: /mymodel.ecore at org.eclipse.core.runtime.Assert.isLegal(Assert.java:63) at org.eclipse.core.internal.resources.Workspace.newResource(Workspace.java:2170) at org.eclipse.core.internal.resources.Container.getFile(Container.java:208) at org.eclipse.emf.compare.ide.utils.ResourceUtil.createURIFor(ResourceUtil.java:227) at org.eclipse.emf.compare.ide.internal.utils.NotLoadingResourceSet.loadResource(NotLoadingResourceSet.java:121) at org.eclipse.emf.compare.ide.internal.utils.NotLoadingResourceSet.create(NotLoadingResourceSet.java:72) at org.eclipse.emf.compare.ide.ui.internal.logical.EMFSynchronizationModel.createScope(EMFSynchronizationModel.java:346) at org.eclipse.emf.compare.ide.ui.internal.logical.EMFSynchronizationModel.createMinimizedScope(EMFSynchronizationModel.java:333) at org.eclipse.emf.compare.ide.ui.internal.structuremergeviewer.EMFCompareStructureMergeViewer.compareInputChanged(EMFCompareStructureMergeViewer.java:344) at org.eclipse.emf.compare.ide.ui.internal.structuremergeviewer.EMFCompareStructureMergeViewer$1.run(EMFCompareStructureMergeViewer.java:260) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53) Klaas, looks like it. No changes are planned on that aspect for now, but this probably isn't a hard fix if you are willing to get your hands a little dirty and contribute. This area of code has changed since the version you are using. Basically, we have one class that tries and work around Team quirks, and that's what you will have to modify : http://git.eclipse.org/c/emfcompare/org.eclipse.emf.compare.git/tree/plugins/org.eclipse.emf.compare.ide.ui/src/org/eclipse/emf/compare/ide/ui/internal/logical/StreamAccessorStorage.java . This class takes an ITypedElement (from the Compare framework) as a parameter and tries to convert it to something it can understand from the Team framework : IFileRevision. The entry point is StreamAccessorStorage.fromTypedElement(ITypedElement), from which we try and find the corresponding IFileRevision by calling StreamAccessorStorage.findFileRevision(ITypedElement). Though our adapting works for CVS, you'll see that we already require some reflexion for EGit. What you need to do is see what SVN gives you as an input of that method, and whether there is a way to find the corresponding IFileRevision through adapters (or reflexion... as a last resort). Fixing that entry point should be enough to allow you to work with models stored on SVN repositories. Please also take a look at the Contributor Guide (http://wiki.eclipse.org/EMF_Compare/Contributor_Guide) if you find a way and are willing to contribute back :). (In reply to comment #4) > Klaas, > > looks like it. Actually it doesn't seem so on a second thought. I can reproduce the issue with a git repository too... (In reply to comment #5) > (In reply to comment #4) > > Klaas, > > > > looks like it. > > Actually it doesn't seem so on a second thought. I can reproduce the issue > with a git repository too... Do you have reproduction steps for us to try and see what's happening (on git repos)? (In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > Klaas, > > > > > > looks like it. > > > > Actually it doesn't seem so on a second thought. I can reproduce the issue > > with a git repository too... > > Do you have reproduction steps for us to try and see what's happening (on > git repos)? (was already working on it :-) See Bug #414180 In last resort, instead of returning the name of the resource as full path, it could return a local compatible path, since it may be interpreted as this in further processing, but non existing one to avoid real file corruption It also keeps the last segment (name and extension) valid, since presentation editor could use it (icons, etc.) See proposed patch. Tested on jazz source control. Created attachment 235418 [details]
Patch proposition
Sorry I never answered here, but the patch as proposed by Bo AR is not acceptable as is. At the time it was submitted, we had already started work on the logical model resolution (resolution of cross-referenced files and handling "as a whole" of this set of files), which made testing even harder, but what this patch did was only hide the errors and made it so that we would corrupt the model with any merge operation afterwards. The path of the files when comparing from SVN should be available in the specific IFileRevisions returned from there and "hidden" behind SVN ITypedElements. What we need is something capable of retrieving the file revision and its path. We have already been forced to use internal means to workaround EGit, CVS forced us to use a pretty strange roundabout... SVN will most likely have the same issue (see "findFileRevision" in StreamAccessorStorage : http://git.eclipse.org/c/emfcompare/org.eclipse.emf.compare.git/tree/plugins/org.eclipse.emf.compare.ide.ui/src/org/eclipse/emf/compare/ide/ui/internal/logical/StreamAccessorStorage.java#n231) Laurent, I had a look at this issue today and afaik there is no easy way to receive an IFileRevision directly from a SVN ResourceElement. What I did is create a new SVNLocalResourceRevision in case of comparing a file from the workspace with a remote revision:
ResourceElement resourceelement = ((ResourceElement)element);
ILocalResource localResource = resourceelement.getLocalResource();
if (localResource != null) {
SVNLocalResourceRevision rev = new SVNLocalResourceRevision(localResource, resourceelement
.getRepositoryResource().getSelectedRevision());
return rev;
}
However, when comparing two remote versions (i.e. from the history view) a SVNRemoteResourceRevision must be created:
IRepositoryResource repoResource = resourceelement.getRepositoryResource();
return new SVNRemoteResourceRevision(repoResource, new SVNLogEntry(repoResource.getRevision(), repoResource.getInfo().lastChangedDate, repoResource.getInfo().lastAuthor, "?", null, false));
This works but the code will get really ugly when you have to do all of this via reflection to reduce svn plugin dependencies. I am not that familiar with the SVN API, maybe you have an idea how to simplify this a bit? EMF Compare is a great feature (especially with the graphical comparison) and it would be great to get it working with SVN...
Andreas, if finding the file revision is impossible in the case of SVN, is it at least possible to retrieve a file path from the revision to the local IResource it represents? The StreamAccessorStorage class is no more than a wrapper around an IStreamContentAccessor (which "ResourceElement" is an instance of) with a proper path associated to it. The one thing we have trouble with is exactly the "find the proper path" part. If you can retrieve this, you should be able to simply create the StreamAccessorStorage from it (look at StreamAccessorStorage#fromTypedElement(...)). Can you try that and see if this enables you to work with SVN? If this is enough to get past the first issues, then the correct course of action is probably for us to first try something like "Platform.getAdapterManager().loadAdapter(typedElement, IStorage.class.getName())" as the very first thing we try when we need to adapt an ITypedElement into an IStorage (EMF Compare works essentially with IStorages), which would allow third-party plugins to use the platform's "org.eclipse.core.runtime.adapters" extension point to provide us with what we need. Laurent, I tried the patch at https://bugs.eclipse.org/bugs/show_bug.cgi?id=414180 and it seems to work. Patch https://git.eclipse.org/r/#/c/29727/ has been proposed through bug 414180 to allow comparisons through Subversive. Subversive is now supported by EMF Compare through the contribution of Jan Reimann from bug 414180. Subclipse is not supported. This support can be installed from the nightly update site http://download.eclipse.org/modeling/emf/compare/updates/nightly/latest and will be available for both Luna SR1 and Mars. *** Bug 440058 has been marked as a duplicate of this bug. *** Backported on the 3.0 maintenance branch as https://git.eclipse.org/c/emfcompare/org.eclipse.emf.compare.git/commit/?h=3.0&id=fe5f4a6f3d9685d24ff3e60b40c3920f645f200b . This will be present in both Mars M1 and Luna SR1. Hi all - I faced similar problem with the latest release of EMF Compare I am using RTC and 3.0.0 RC4 (2014/06/11 13:28)version of EMF Compare. As suggested by Laurent in his last few comment - I used the latest nightly build and seems like the issue is resolved. This is good - thanks! Now may I please know when the next RC build of release 3.0.0 will be made available (as a p2 zip file) please Many Thanks ! (In reply to Preetam Palwe from comment #18) > Hi all - I faced similar problem with the latest release of EMF Compare > I am using RTC and 3.0.0 RC4 (2014/06/11 13:28)version of EMF Compare. > > As suggested by Laurent in his last few comment - I used the latest nightly > build and seems like the issue is resolved. This is good - thanks! > > Now may I please know when the next RC build of release 3.0.0 will be made > available (as a p2 zip file) please > > Many Thanks ! As mentionned in my comment #17, this will be present in Luna SR1, which will be released this friday as per the release schedule http://wiki.eclipse.org/Luna/Simultaneous_Release_Plan#SR1. Thanks for responding Laurent. Helpful to know SR1 release date of Luna. I am not close to the release management here hence may be a repeat question - As per the note on https://wiki.eclipse.org/Luna/Simultaneous_Release_Plan#SR1 "The 'promote period' (9/22 to 9/25) will be the time projects put final zips and repository artifacts in their final release location (but, without displaying them or making them visible to p2) so they can propagate through the mirroring system (but not generally be "visible" to end users or p2, so that there really is a "simultaneous maintenance release"). At 9 AM (Eastern) on the GA date projects can make their final maintenance releases visible. (Be sure to check cross-project list, first, to make sure there's not any last-minute blocking problems or changes to exact times)." My understanding is the p2 of EMF Compare will be made available on http://www.eclipse.org/emf/compare/downloads/ over the weekend. Am I correct? Thanks ! I think I am good now with 3.0.1 RC1 - Thanks ! (In reply to Preetam Palwe from comment #21) > I think I am good now with 3.0.1 RC1 - Thanks ! Sorry, I was sure I had answered your previous comment, but it seems like I didn't. Basically, our releases are always available a little before the "final" release date of the release train, in the form of release candidates : the "release" version is a verbatim copy of our latest RC. However, the safest mean to retrieve our releases is to wait for them to be made available on the release train's repository (http://download.eclipse.org/releases/luna in this case), on our own "latest" update site (only updated for "releases", so 3.0.1 is there but 3.1.0M2 isn't), or look at our download page from time to time. In the current case, "3.0.1" is identical to "3.0.1RC1", so you have the correct version (there were no blocking bugs in RC1). |