Same here. Appears to be benign - our builds still work - but we get the following message all over our logs:

AssertionError: appears to be using unpatched svnkit at file:/C:/Users/jenkins/AppData/Local/Temp/hudson-remoting7710290003783506449/org/tmatesoft/svn/core/wc/SVNEvent.class

Jenkins version 1.464
Jenkins Subversion Plug-in version 1.40 (appears to be pinned, and not manually by us)

Windows Server 2003 x86
VisualSVN Server (SVN 1.7.1 (r1186859))

After upgrading the SVN plugin from 1.39 -> 1.40, all externals trigger this assertion. The builds themselves succeeds. The builds use a clean checkout with client version 1.7
Using SVN server version 1.7
AssertionError: appears to be using unpatched svnkit at file:/C:/Users/Jenkins/AppData/Local/Temp/hudson-remoting652945517889234834/org/tmatesoft/svn/core/wc/SVNEvent.class

Same here on Linux platform.

As a nasty side-effect, also the externals' revision information in <build directory>/revision.txt is missing. The file only contains the revision of the main repository.

We are also missing the externals revision information. Builds are also not triggered anymore on a change of an external.

We are seeing the same issue after updating to 1.40. The job fails. This is the output:

AssertionError: appears to be using unpatched svnkit at file:/tmp/hudson-remoting6567098393035999821/org/tmatesoft/svn/core/wc/SVNEvent.class
At revision 5215
AssertionError: appears to be using unpatched svnkit at file:/tmp/hudson-remoting6567098393035999821/org/tmatesoft/svn/core/wc/SVNEvent.class
FATAL: hudson.remoting.RequestAbortedException: java.io.StreamCorruptedException: invalid type code: 41
hudson.remoting.RequestAbortedException: hudson.remoting.RequestAbortedException: java.io.StreamCorruptedException: invalid type code: 41
	at hudson.remoting.Request.call(Request.java:149)
	at hudson.remoting.Channel.call(Channel.java:646)
	at hudson.FilePath.act(FilePath.java:821)
	at hudson.FilePath.act(FilePath.java:814)
	at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:743)
	at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:685)
	at hudson.model.AbstractProject.checkout(AbstractProject.java:1218)
	at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:581)
	at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:470)
	at hudson.model.Run.run(Run.java:1434)
	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
	at hudson.model.ResourceController.execute(ResourceController.java:88)
	at hudson.model.Executor.run(Executor.java:239)
Caused by: hudson.remoting.RequestAbortedException: java.io.StreamCorruptedException: invalid type code: 41
	at hudson.remoting.Request.abort(Request.java:273)
	at hudson.remoting.Channel.terminate(Channel.java:702)
	at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:69)
Caused by: java.io.StreamCorruptedException: invalid type code: 41
	at java.io.ObjectInputStream.readObject0(Unknown Source)
	at java.io.ObjectInputStream.readObject(Unknown Source)
	at hudson.remoting.Command.readFrom(Command.java:90)
	at hudson.remoting.ClassicCommandTransport.read(ClassicCommandTransport.java:59)
	at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48)

I have probably the same problem and I'm getting frustrated because I really don't know how to solve it (using Jenkins 1.470, Subversion Plugin 1.40, Check-out Strategy: "Emulate clean checkout by...")

The repository contains an external directory. Within the Main folder I changed a source file (main.c), but the changes are not updated in jobs workspace directory at the beginning of the run. Does anybody know why? Is it a bug or maybe just a wrong configuration?

If it's a subversion plugin problem: Is there a newer version? How could I install that version?

The log:

Building in workspace C:\Jenkins\Config\jobs\WAP2-Trunk_DB-Build\workspace
Cleaning up C:\Jenkins\Config\jobs\WAP2-Trunk_DB-Build\workspace\.
Deleting C:\Jenkins\Config\jobs\WAP2-Trunk_DB-Build\workspace\BuildPlan.xml
Deleting C:\Jenkins\Config\jobs\WAP2-Trunk_DB-Build\workspace\WLP.c
Updating https://repos.xxx.com/svn/trunk
U         main.c
AssertionError: appears to be using unpatched svnkit at jar:file:/C:/Jenkins/Config/plugins/subversion/WEB-INF/lib/svnkit-1.7.4-jenkins-1.jar!/org/tmatesoft/svn/core/wc/SVNEvent.class
At revision 11875
At revision 11874
no change for https://repos.xxx.com/svn/trunk since the previous build

Stephan,
We downgraded to 1.39 and it seems to have "solved" the problem. YMMV.

Because of some build scripts we need the subversion 1.7 working copy format. as I know, the version 1.39 of the subversion plugin does use the 1.6 working copy format. is someone working on a solution?

So you don't need the subversion 1.7 working copy format?

No we don't need subversion 1.7. We upgraded because of a another problem ("org.tmatesoft.svn.core.SVNException: svn: REPORT /seesaw/!svn/vcc/default failed", "Checksum mismatch while updating '/jenkins-directory/products/run/.svn/text-base/RUN_ALL.svn-base'; expected: '6d28a7249c635f15621f5f5ac5fa28d2', actual: 'null'")

It looks like the build has happened on a slave, can you tell us about how this slave is connected? SSH, Java Web Start, etc.

If you are not sure, just let us know the name of the slave and attach $JENKINS_HOME/config.xml.

We have the same problem with 0.40.

I don't think its dependent on how the slaves are connected. Our Linux Slaves are connected via SSH and our windows slaves via DCOM/Windows Service. Both slave-types get that error on 1.6 subversion format. We reverted back to 0.39 too now to get it working again.

It is also not triggering a build when an external changes.

Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
svnkit/src/main/java/org/tmatesoft/svn/core/internal/wc16/SVNUpdateClient16.java
http://jenkins-ci.org/commit/svnkit/bfddf2421bd7d148fad628471dd6d19ee40cd759
Log:
JENKINS-13790 Added svn:externals information to callback

Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
pom.xml
http://jenkins-ci.org/commit/subversion-plugin/79cdc08cfd7baa77cce4fdda7134c0b898cea7f1
Log:
Pick up fix for JENKINS-13790

Fixed toward 1.41.

Issue is still present with 1.42.
File/Folder externals are updated correctly but are always coupled with the same following error:
AssertionError: appears to be using unpatched svnkit at jar:xxx/SVNEvent.class

Subversion plugin v1.42 solves the issue for me. Now i dont get "AssertionError: appears to be using unpatched svnkit " error. I am building in Windows Slave connected to Linux Jenkins server via "WebStart".

update svn plugin to version 1.42, but still have this issue.

AssertionError: appears to be using unpatched svnkit at jar:file:/E:/Jenkins/plugins/subversion/WEB-INF/lib/svnkit-1.7.4-jenkins-3.jar!/org/tmatesoft/svn/core/wc/SVNEvent.class

A number of users are still experiencing the AssertionError.

I can confirm this issue with 1.42, too.

Can we get an update on this? It has twice caused me to load the plugin, upgrade my workspaces, and have to revert them back because it doesn't work properly.

Jenkins 1.457 + Tortoise 1.7.7 + Subversion plugin 1.40 seems to cause a problem when reading externals:

AssertionError: appears to be using unpatched svnkit at jar:file:/C:/Program%20Files%20(x86)/Jenkins/plugins/subversion/WEB-INF/lib/svnkit-1.7.4-jenkins-1.jar!/org/tmatesoft/svn/core/wc/SVNEvent.class

Can someone on Jenkins development team have a look?

I am also seeing this problem. I have just installed the latest Jenkins (now 1.474) on a brand-new Windows 7 machine. The plugin manager in Jenkins told me that the Subversion plugin was out of date (it was version 1.39), so I updated it to the latest one (1.42) before starting to set up my builds. These same builds had worked fine on a different Windows 7 machine, which was running Jenkins 1.441 with version 1.34 of the Subversion plugin.

When my builds checked their sources out of Subversion I got this message:
AssertionError: appears to be using unpatched svnkit at jar:file:/Q:/jenkins/plugins/subversion/WEB-INF/lib/svnkit-1.7.4-jenkins-3.jar!/org/tmatesoft/svn/core/wc/SVNEvent.class

These builds are performed entirely on the (Windows) master, not on any slaves.

Our repositories use svn externals, so I assume I am seeing the same problem that others have reported here.

I am having trouble going back to version 1.39 of the Subversion plugin, because of the incompatibility in working copy layout between svn 1.6 and 1.7 (I have also installed TortoiseSVN and the command-line svn client, and I want to use Subversion 1.7 for everything on this new machine). I would really appreciate a fix for this bug so that I can use a version of the plugin that is compatible with svn 1.7.

Update to use SVNKit version 1.7.5 may help with the externals issue, because there are some fixies about the svn:externals.

We are also working with a lot of externals in our projects. And they still not working in 1.4.2 / 1.446.1 (configured to use workspace 1.7).
How can we help, to find a resolution for this problem?

Is there any activity on this issue?

Has anyone got a fix for this problem?

We are running version 1.467 and plugin version 1.42 and are seeing the same issue.

How can we increase the priority of fixing this bug?

In my opinion it is an important bug-fix, because at the moment we have to always check out a fresh copy of our svn repository to be sure the working directory is up to date. And this takes (too) much time and leads to (too) much traffic on the server.

(Context: Windows server/slave - AssertionError: appears to be using unpatched svnkit) Ran into this same/similar problem locally. On the slave machine there was a second svn.exe located in a different path (sliksvn client). It was an older version of svn.exe and caused this exact error message. Just to 'cover the bases' you can type svn --version in the command line on the slave.

I just have the checked the sources and found out, that only the wc16 is supported for the externals. There is a missing support for wc17. So in an old project, where still the working copy was in format 16, I was able to update. Using a fresh checkout it generates version 17 and the externals fail.
So there is a need to update the patched svnkit to support the new working copy format.

I went now back to use subversion 1.6 working copy format (main settings) and it works fine. Be sure that you delete the existing working copies & rerun the builds. Otherwise it keep using the 1.7 working copy.

Jan,
This is exactly what I had to do as well. Our instance is running as expected now.

-Dewayne

I'm using 1.4.3, see this error still.

Rattapon,

You may have to revert your plugin back to the previous version and also make sure you are using Subversion 1.6 working copy format(main settings). then you also must start with a fresh workspace for the Jenkins job so a fresh checkout is made.

Have you done this?

-Dewayne

Seeing the same error in my build logs for 1.486, but the error doesn't appear to be fatal. The rest of the repo checks out properly and the build works fine.

14:43:45 AssertionError: appears to be using unpatched svnkit at file:/tmp/hudson-remoting4395012546022522440/org/tmatesoft/svn/core/wc/SVNEvent.class

This is with svn 1.7.

Oct 29 there was a new svnkit released which mentions it is fixed for SVN 1.7 server and working directories.... Will there be a Jenkins upgrade soon that uses the latest svnkit?

This issue also causes workspace cleanup failure when "Emulate clean checkout" is used. Seams to keep the old files intact.

I hit...
AssertionError: appears to be using unpatched svnkit at jar:file:/D:/Jenkins/plugins/subversion/WEB-INF/lib/svnkit-1.7.4-jenkins-3.jar!/org/tmatesoft/svn/core/wc/SVNEvent.class

Hi Nick, the problem is, that the "patched" svnkit is already in use, but the "patches" for subversion 1.7 are still missing.
May be you could write to the mailing list, because here seems none of the plugin developers to listen.

I have a fix for this within my fork of the plugin on github. It uses the native support within SVNKit to determine the URLs for the svn:externals that the project contains. Because it natively hooks into SVNKit it works regardless of the SVN version you wish to use in your working copies. The pull request is https://github.com/jenkinsci/subversion-plugin/pull/30.

Many thanks to Tom Palmer for his fix. I've manually built the SVN plugin with his mods (followed instructions here: https://wiki.jenkins-ci.org/display/JENKINS/Plugin+tutorial#Plugintutorial-BuildingaPlugin) and svn:externals polling functionality seems to be restored. I've tested this with multiple Jenkins projects with wc 1.7 with many, many directory externals without any issues. The only thing I haven't tested are file externals, which I know were also problematic with recent official releases of the plugin.

Code changed in jenkins
User: Tom Palmer
Path:
src/main/java/hudson/scm/SubversionSCM.java
src/main/java/hudson/scm/subversion/CheckoutUpdater.java
src/main/java/hudson/scm/subversion/SubversionUpdateEventHandler.java
src/main/java/hudson/scm/subversion/UpdateUpdater.java
http://jenkins-ci.org/commit/subversion-plugin/1e685c2e58160f8353d52ba92a6066a39f107443
Log:
[FIXED JENKINS-13790] Use the native SVNKit ISVNExternalsHandler to pick up the svn:externals URLs.

Compare: https://github.com/jenkinsci/subversion-plugin/compare/b20cf6430106...1e685c2e5816