JavaHL Error in Subclipse

Question

I'm trying to create a new phonegap project in a new repository. When ever I add a new folder or file I get the following error. This is a completely fresh copy of eclipse in a new workspace and fresh install of subclipse.

Errors occurred while updating the change sets for SVNStatusSubscriber

org.apache.subversion.javahl.ClientException: svn: E155007: 'Workspace/PhoneGap/www/js' is not a working copy

org.apache.subversion.javahl.ClientException: svn: E155007: 'Workspace/PhoneGap/www/js' is not a working copy

org.apache.subversion.javahl.ClientException: svn: E155007: 'Workspace/PhoneGap/www/js' is not a working copy

I've no idea what is causing the issue, everything I've found through google has said a fresh install or fresh workspace should fix the issue. I've also selected SVNKit to be the SVN Client as I've had issues with JavaHL before and the fix was to switch to SVNKit.

Eclipse Installation and Versions:

Answer 1

For whatever reason, it looks like the SVNKit 1.7.x API (which is still in beta) does not think that folder is a working copy. I cannot really say if it is right/wrong or why, but that is the error the API is throwing.

They have released a beta2 recently. You could get that update from their update site.

If you have SVN 1.7.x command line you could use it to examine the WC and that folder using the svn status command.

Answer 2

I have the same issue, but get the error in my /bin folder. Obviously my /bin folder is not svn-added to my remote svn server... because we don't want to keep binaries in addition to source in svn.

After trying to clean-build my projects, I got the same error. I assumed the svn plugin was somehow mucking stuff up, and disabled them. (in osgi console, stop all the id's related to svn).

I then got hte following stack trace:

java.lang.NullPointerException
at org.tigris.subversion.subclipse.core.SVNClientManager.getAdapter(SVNClientManager.java:127)
at org.tigris.subversion.subclipse.core.SVNClientManager.getSVNClient(SVNClientManager.java:94)
at org.tigris.subversion.subclipse.core.SVNProviderPlugin.getSVNClient(SVNProviderPlugin.java:462)
at org.tigris.subversion.subclipse.core.repo.SVNRepositoryLocation.getSVNClient(SVNRepositoryLocation.java:274)
at org.tigris.subversion.subclipse.core.resources.SVNMoveDeleteHook.deleteResource(SVNMoveDeleteHook.java:47)
at org.tigris.subversion.subclipse.core.resources.SVNMoveDeleteHook.deleteFolder(SVNMoveDeleteHook.java:110)
at org.eclipse.team.internal.core.MoveDeleteManager.deleteFolder(MoveDeleteManager.java:62)
at org.eclipse.core.internal.resources.Resource.unprotectedDelete(Resource.java:1940)
at org.eclipse.core.internal.resources.Resource.delete(Resource.java:780)
at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.cleanOutputFolders(BatchImageBuilder.java:114)
at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.build(BatchImageBuilder.java:46)
at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildAll(JavaBuilder.java:254)
at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:173)
at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:728)

Now this stack trace is due to me stopping the plugins, but, it does give a clue what was happening before I disabled the plugins.

It seems that svnkit is now treating the deletion of my bin folder (which gets deleted as part of a clean build process) as an error, since my bin folder has no .svn subfolder (aka is not a working copy).

So this means their code somehow assumes that all folders should be a working copy, and if they're not it's an error. Their code seems to ignore hte possibility that I might have a folder in my local tree that I do not want to commit remotely.

balls.

Answer 3

I had the same annoying problem with bin complaining. I checked in workspace/preferences/Team/svn

There in client, I had option of SVNKit or JavaHL. I changed mine from javahl to SVNkit and restarted. The problem seems to have gone :-)

I also deleted the bin folders for the complaining projects and did the above. Maybe combination should work for other cases. I presume it was the JavaHL that was the problem.

Answer 4

I also got this error after upgrading my Eclipse.

svn: E155007 '/somepath' is not a working copy

The reason was that I was still running SVN 1.6 on my MacOSX machine (run svn --version on command line) but downloaded Subclipse 1.10 which seems to require SVN 1.8

I had to install Subclipse 1.6 in order to remove this strange message.

Side note: After re-installing subclipse, I also had to remove all bundles in the project and import them again, so that the SVN folders got recognized