3

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: enter image description here

Community
  • 1
  • 1
Nalum
  • 4,143
  • 5
  • 38
  • 55
  • I'm having the same issue, but even with all of the latest-available software. I've filed an issue report against this at http://issues.tmatesoft.com/issue/SVNKIT-232. – ziesemer Mar 24 '12 at 18:42

4 Answers4

2

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.

Mark Phippard
  • 10,329
  • 2
  • 32
  • 42
  • 1
    Thanks for your response. Beta2 has the same issue so I've downgraded to subclipse 1.6 – Nalum Mar 06 '12 at 10:19
  • Does that mean you checked out your projects from scratch? If not, then maybe that is your problem. SVN 1.7 introduced a new working copy format. Before you can use an existing SVN 1.6 working copy you have to use the Team > Upgrade option to convert it to the SVN 1.7 format. – Mark Phippard Mar 06 '12 at 13:54
  • I was starting a new project and had to install a eclipse java as I normally work with Zend Studio so the repository was new and was checked out with the new install. I wasn't aware of it, but the subversion server we have is not the latest version. So that was the problem. – Nalum Mar 08 '12 at 11:54
1

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.

Benoit
  • 1,995
  • 1
  • 13
  • 18
rawb
  • 11
  • 1
1

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.

McGarnagle
  • 101,349
  • 31
  • 229
  • 260
sandhya
  • 11
  • 1
0

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

Christoph
  • 3,980
  • 2
  • 40
  • 41