Bug 254878 - Grid Project connected to SVN with Connections added. Deleting of connection/files/folders fails
Summary: Grid Project connected to SVN with Connections added. Deleting of connection/...
Status: NEW
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: Geclipse (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P3 major (vote)
Target Milestone: ---   Edit
Assignee: Thomas Kockerbauer CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 257500
Blocks:
  Show dependency tree
 
Reported: 2008-11-11 08:29 EST by Asterios Katsifodimos CLA
Modified: 2014-01-09 16:01 EST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Asterios Katsifodimos CLA 2008-11-11 08:29:51 EST
Suppose that I have a project and some connections in it. 
I submit the Project to the SVN server(I have tried both JavaHL and SVNKit implementations with Subversive).

Commiting the project leads to errors like this:
Get all resources operation failed.
0x00000014: Resource is inaccessible or it is not under SVN control


SVN thinks those are files but in fact they are not. 
They are some records into the .project file.

I think this is happening because you use something like "links" for the connections.

In order to be able to commit the project you have to "disconnect" the project, delete the connections and then commit it. If you don't disconnect, the Connections cannot be deleted nor anything of the files/folders into storage elements.

Could someone investigate how to overcome this?
SVN saving of Grid projects is really important for users.
Comment 1 Ariel Garcia CLA 2008-11-25 09:47:14 EST
Yes the connections are Eclipse linked resources, but no clue how to deal with that in SVN/CVS projects.

Thomas, you have been investigating a problem when checking projects out from CVS, was it related to this one, or any comment?

Also adding Mathias.
Comment 2 Thomas Kockerbauer CLA 2008-12-02 06:31:53 EST
It seems to work for me (I've tried subclipse with svnkit). Are you using Subversive or Subclipse?

The Eclipse CVS plugin handles linked filesystems like local directories and also tries to do revision control on those subdirectories. It seems that Subclipse does not do any revision control on linked filesystems.
Comment 3 Thomas Kockerbauer CLA 2008-12-02 07:49:34 EST
I could reproduce the problem with Subversive. If you want to have a quick fix: use Subclipse (which is better anyway imho). I will have a deeper look into the problem.
Comment 4 Thomas Kockerbauer CLA 2008-12-02 09:01:20 EST
Here is the exception thrown by subversive:

org.eclipse.team.svn.core.operation.UnreportableException: 0x00000014: Resource is inaccessible or it is not under SVN control
at org.eclipse.team.svn.core.utility.FileUtility.getResourcePath(FileUtility.java:126)
at org.eclipse.team.svn.core.utility.FileUtility.getWorkingCopyPath(FileUtility.java:119)
at org.eclipse.team.svn.core.svnstorage.SVNRemoteStorage$4.visit(SVNRemoteStorage.java:544)
at org.eclipse.team.svn.core.utility.FileUtility.visitNodes(FileUtility.java:285)
at org.eclipse.team.svn.core.svnstorage.SVNRemoteStorage.loadUnversionedSubtree(SVNRemoteStorage.java:536)
at org.eclipse.team.svn.core.svnstorage.SVNRemoteStorage.loadLocalResourcesSubTree(SVNRemoteStorage.java:524)
at org.eclipse.team.svn.core.svnstorage.SVNRemoteStorage.asLocalResource(SVNRemoteStorage.java:319)
at org.eclipse.team.svn.core.SVNTeamMoveDeleteHook.doDelete(SVNTeamMoveDeleteHook.java:121)
at org.eclipse.team.svn.core.SVNTeamMoveDeleteHook.deleteFolder(SVNTeamMoveDeleteHook.java:56)
at org.eclipse.team.internal.core.MoveDeleteManager.deleteFolder(MoveDeleteManager.java:62)
at org.eclipse.core.internal.resources.Resource.unprotectedDelete(Resource.java:1715)
at org.eclipse.core.internal.resources.Resource.delete(Resource.java:706)
at org.eclipse.ltk.core.refactoring.resource.DeleteResourceChange.perform(DeleteResourceChange.java:139)
at org.eclipse.ltk.core.refactoring.CompositeChange.perform(CompositeChange.java:278)
at org.eclipse.ltk.core.refactoring.CompositeChange.perform(CompositeChange.java:278)
at org.eclipse.ltk.core.refactoring.PerformChangeOperation$1.run(PerformChangeOperation.java:260)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1800)
at org.eclipse.ltk.core.refactoring.PerformChangeOperation.executeChange(PerformChangeOperation.java:308)
at org.eclipse.ltk.internal.ui.refactoring.UIPerformChangeOperation.access$1(UIPerformChangeOperation.java:1)
at org.eclipse.ltk.internal.ui.refactoring.UIPerformChangeOperation$1.run(UIPerformChangeOperation.java:66)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at org.eclipse.ltk.internal.ui.refactoring.UIPerformChangeOperation$2.run(UIPerformChangeOperation.java:84)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:133)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3378)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3036)
at org.eclipse.jface.operation.ModalContext$ModalContextThread.block(ModalContext.java:172)
at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:370)
at org.eclipse.ltk.internal.ui.refactoring.RefactoringWizardDialog2.run(RefactoringWizardDialog2.java:317)
at org.eclipse.ltk.ui.refactoring.RefactoringWizard.internalPerformFinish(RefactoringWizard.java:558)
at org.eclipse.ltk.ui.refactoring.UserInputWizardPage.performFinish(UserInputWizardPage.java:154)
at org.eclipse.ltk.ui.refactoring.resource.DeleteResourcesWizard$DeleteResourcesRefactoringConfigurationPage.performFinish(DeleteResourcesWizard.java:147)
at org.eclipse.ltk.ui.refactoring.RefactoringWizard.performFinish(RefactoringWizard.java:622)
at org.eclipse.ltk.internal.ui.refactoring.RefactoringWizardDialog2.okPressed(RefactoringWizardDialog2.java:446)
at org.eclipse.jface.dialogs.Dialog.buttonPressed(Dialog.java:472)
at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.java:624)
at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:228)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1158)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3401)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3033)
at org.eclipse.jface.window.Window.runEventLoop(Window.java:825)
at org.eclipse.jface.window.Window.open(Window.java:801)
at org.eclipse.ltk.ui.refactoring.RefactoringWizardOpenOperation$1.run(RefactoringWizardOpenOperation.java:144)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
at org.eclipse.ltk.ui.refactoring.RefactoringWizardOpenOperation.run(RefactoringWizardOpenOperation.java:156)
at org.eclipse.ltk.internal.ui.refactoring.actions.DeleteResourcesHandler.execute(DeleteResourcesHandler.java:41)
at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:281)
at org.eclipse.core.commands.Command.executeWithChecks(Command.java:476)
at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:508)
at org.eclipse.ui.internal.handlers.HandlerService.executeCommandInContext(HandlerService.java:270)
at org.eclipse.ui.internal.ide.actions.LTKLauncher.runCommand(LTKLauncher.java:95)
at org.eclipse.ui.internal.ide.actions.LTKLauncher.openDeleteWizard(LTKLauncher.java:47)
at org.eclipse.ui.actions.DeleteResourceAction.run(DeleteResourceAction.java:480)
at eu.geclipse.ui.internal.actions.DeleteGridElementAction.deleteOtherResources(DeleteGridElementAction.java:211)
at eu.geclipse.ui.internal.actions.DeleteGridElementAction.run(DeleteGridElementAction.java:107)
at org.eclipse.ui.actions.BaseSelectionListenerAction.runWithEvent(BaseSelectionListenerAction.java:168)
at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:583)
at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:500)
at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:411)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1158)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3401)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3033)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2382)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2346)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2198)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:493)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:288)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:488)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:113)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:193)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:382)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:549)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504)
at org.eclipse.equinox.launcher.Main.run(Main.java:1236)

I had a look into the subversive code at the location where the exception is thrown, they seem to iterate over the resources and if it is not a ".svn" directory it does the following:
	
	public static IPath getResourcePath(IResource resource) {
		IPath location = resource.getLocation();
		if (location == null) {
			String errMessage = SVNMessages.formatErrorString("Error_InaccessibleResource_2", new String[] {resource.getFullPath().toString()}); //$NON-NLS-1$
			throw new UnreportableException(errMessage);
		}
		return location;
	}

This means that the code will not work with anything that does return null for getLocation() (i.e. remote filesystems). I guess we can not do much about that except create a bug report for subversive.
Comment 5 Thomas Kockerbauer CLA 2008-12-04 06:20:09 EST
Just for the record: I've added an entry to the known issues section of the documentation.