Addition of new folders under WC in Subclipse logs svn: E155007 ClientExceptions - "not a working copy" as errors : SVNKIT-232

commenter: me

Showing issue #88 of 113 found

Project	SVNKit
Priority	Major
Type	Bug
State	Fixed
Assignee	Alexander Kitaev
Subsystem	JavaHL
Affected versions	1.7.0
Fix versions	No Fix versions
Fixed in build	No Fixed in build

Created by Mark A. Ziesemer
14 months ago (24 Mar 2012 20:40)
Updated by guest
14 months ago (16 Apr 2012 18:46)

SVNKIT-232 Addition of new folders under WC in Subclipse logs svn: E155007 ClientExceptions - "not a working copy" as errors

Issue is visible to: All Users

This is almost an identical issue to http://stackoverflow.com/questions/9570937/javahl-error-in-subclipse.

As the SO-linked question indicates, whenever a new folder is added anywhere underneath a WC in Subclipse, this error is logged with "Error" severity in the Eclipse error log. (However, I don't always get the "Errors occurred while updating the change sets for SVNStatusSubscriber" pop-up.) It doesn't matter if these folders are created by Eclipse itself (e.g. Project/Clean) - or if creating the folder manually within the project tree.

Here is the stack trace from one such error. Note that I've replaced full disk paths with "..." - where "..." is the root of a 1.7 working copy:

org.tigris.subversion.subclipse.core.SVNException: org.apache.subversion.javahl.ClientException: svn: E155007: '...\target\classes' is not a working copy

…

org.tigris.subversion.subclipse.core.SVNException: org.apache.subversion.javahl.ClientException: svn: E155007: '...\target\classes' is not a working copy
 at org.tigris.subversion.subclipse.core.SVNException.wrapException(SVNException.java:101)
 at org.tigris.subversion.subclipse.core.status.StatusCacheManager.refreshStatus(StatusCacheManager.java:293)
 at org.tigris.subversion.subclipse.core.resourcesListeners.FileModificationManager.refreshStatusInfitite(FileModificationManager.java:170)
 at org.tigris.subversion.subclipse.core.resourcesListeners.FileModificationManager.resourceChanged(FileModificationManager.java:154)
 at org.eclipse.core.internal.events.NotificationManager$1.run(NotificationManager.java:291)
 at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
 at org.eclipse.core.internal.events.NotificationManager.notify(NotificationManager.java:285)
 at org.eclipse.core.internal.events.NotificationManager.broadcastChanges(NotificationManager.java:149)
 at org.eclipse.core.internal.resources.Workspace.broadcastPostChange(Workspace.java:395)
 at org.eclipse.core.internal.resources.Workspace.endOperation(Workspace.java:1530)
 at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:156)
 at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241)
 at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Caused by: org.tigris.subversion.subclipse.core.SVNException: org.apache.subversion.javahl.ClientException: svn: E155007: '...\target\classes' is not a working copy
 at org.tigris.subversion.subclipse.core.SVNException.wrapException(SVNException.java:91)
 at org.tigris.subversion.subclipse.core.status.RecursiveStatusUpdateStrategy.statusesToUpdate(RecursiveStatusUpdateStrategy.java:66)
 at org.tigris.subversion.subclipse.core.status.StatusCacheManager.refreshStatus(StatusCacheManager.java:270)
 ... 11 more
Caused by: org.tigris.subversion.svnclientadapter.SVNClientException: org.apache.subversion.javahl.ClientException: svn: E155007: '...\target\classes' is not a working copy
 at org.tigris.subversion.svnclientadapter.javahl.AbstractJhlClientAdapter.getStatus(AbstractJhlClientAdapter.java:592)
 at org.tigris.subversion.svnclientadapter.javahl.AbstractJhlClientAdapter.getStatus(AbstractJhlClientAdapter.java:550)
 at org.tigris.subversion.svnclientadapter.svnkit.SvnKitClientAdapter.getStatus(SvnKitClientAdapter.java:107)
 at org.tigris.subversion.svnclientadapter.javahl.AbstractJhlClientAdapter.getStatus(AbstractJhlClientAdapter.java:543)
 at org.tigris.subversion.svnclientadapter.javahl.AbstractJhlClientAdapter.getStatus(AbstractJhlClientAdapter.java:536)
 at org.tigris.subversion.subclipse.core.status.RecursiveStatusUpdateStrategy.statusesToUpdate(RecursiveStatusUpdateStrategy.java:63)
 ... 12 more
Caused by: org.apache.subversion.javahl.ClientException: svn: E155007: '...\target\classes' is not a working copy
 at org.apache.subversion.javahl.ClientException.fromException(ClientException.java:68)
 at org.tmatesoft.svn.core.javahl17.SVNClientImpl.status(SVNClientImpl.java:267)
 at org.tigris.subversion.svnclientadapter.javahl.AbstractJhlClientAdapter.getStatus(AbstractJhlClientAdapter.java:570)
 ... 17 more

These errors only happen when "SVNKit (Pure Java) SVNKit v1.7.0.SNAPSHOT" is chosen as the "SVN interface" in the Subclipse preferences. Choosing JavaHL (JNI) 1.7.4 (r1295709)" instead eliminates these issues - but causes other issues for why we prefer to use SVNKit (e.g. not caching credentials in-memory without committing to disk, encrypted or not).

Here are my specific product versions involved:

Eclipse 3.7.2 (Indigo Service Release 2 / 20120216-1857)
jdk1.7.0_03, Windows 7, both 64-bit
Subclipse (Required) 1.8.7
Subversion Client Adapter (Required) 1.8.1
Subversion JavaHL Native Library Adapter (Required) 1.7.4
SVNKit Client Adapter - BETA (Not required) 1.7.0
SVNKit Library 1.7.4.rc2_t20120323_1452
JNA Library 3.4.0.t20120117_1605

Please let me know if this should be filed against Subclipse instead - or if there is any other details I can offer, or anything else I can do to assist.

Thanks!

Alexander Kitaev

26 Mar 2012 17:13

14 months ago

Is this issue reproducible with JavaHL adapter enabled instead of SVNKit? If so then it should be reported against Subclipse... I'll check it soon.

Mark A. Ziesemer

26 Mar 2012 17:48

14 months ago

Alexander - No, as mentioned in the report, these issues are not observable when choosing the JavaHL adapter instead of SVNKit.

Alexander Kitaev

26 Mar 2012 18:51

14 months ago

Thanks, I found the reason of the problem and fixed it in trunk. We'll publish rc3 build tomorrow with the fix included.
Both native JavaHL and SVNKit implementation throws an exception, but SVNKit did not set error code on an exception thrown, while Subclipse relied on it to skip this exception.

Related Changes

Resolved Date

14 months ago (26 Mar 2012 18:52)

State

Submitted→ Fixed

guest

02 Apr 2012 11:47

14 months ago

Alexander - has this issue been solved? its very irritating to keep getting this popup