Answering my own question... apparently there exists a config property in Jenkins called "Subversion Workspace Version" (under http://server/jenkins/configure) that governs this setting.
Apparently the Jenkins Subversion Plugin 1.42 has problems updating a manually checked out 1.7 workspace with externals if that configuration setting does not specify a 1.7 format. Apparently this setting defaults to an SVN 1.4 working copy format, at least that's what I observe in Jenkins 1.474. On Thu, Jul 19, 2012 at 12:36 PM, Carlton Brown <[email protected]>wrote: > Is it expected behavior that the Subversion Plugin 1.42 is not compatible > with SVN 1.7 working copies? Also, is it expected that Jenkins will check > out new working copies in the SVN 1.4 format? > > When I manually check out using svn 1.7, and direct Jenkins to use that > working copy, Jenkins fails to update. It happens regardless of whether > the protocol is http or svn. This is the error: > > AssertionError: appears to be using unpatched svnkit at > jar:file:/usr/share/tomcat6/.jenkins/plugins/subversion/WEB-INF/lib/svnkit-1.7.4-jenkins-3.jar!/org/tmatesoft/svn/core/wc/SVNEvent.class > > > I thought after all that recent work, the plugin would be compatible with > 1.7 working copies. Is that not true? > > Additionally, a project checked out as a clean workspace shows a value of > '8' in .svn/format which signifies that the Subversion 1.4 working copy > format. In fact those .svn metadata folders are found in every > subdirectory, recursively. I hoped we'd be done with all those droppings > after updating to the Subversion 1.42 plugin. > > This is on Jenkins 1.474 on Linux. > > > >
