Question about working copy format used by Jenkins Subversion plugin 1.42

[Carlton Brown]

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.

[Carlton Brown]

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.   

[Sarah Woodall]

On 19/07/2012 21:03, Carlton Brown wrote:
> 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.

Ah, is _that_ the way to work round the bug? I have lost so much time
over this problem! See Jenkins JIRA issue 13790. Are you telling me that
all I need to do is change this setting in the configuration and my
problems will be over?

> Apparently this setting defaults to an SVN 1.4 working copy format, at
> least that's what I observe in Jenkins 1.474.

Yes, I had seen that it defaulted to 1.4. I did wonder why. I _thought_
I had changed it to 1.7 and that I still saw the problem, but perhaps I
am confused.

--
Sarah Woodall
Code Red Technologies

[Carlton Brown]

On Thu, Jul 19, 2012 at 4:19 PM, Sarah Woodall <sarah....@code-red-tech.com> wrote:

On 19/07/2012 21:03, Carlton Brown wrote:

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.

Ah, is _that_ the way to work round the bug? I have lost so much time over this problem! See Jenkins JIRA issue 13790. Are you telling me that all I need to do is change this setting in the configuration and my problems will be over?

After further, I'm afraid it's a bit more subtle than that.   If Jenkins had ever tried to update that WC as if it were a 1.4 WC, and encountered that error, then the Jenkins workspace metadata is somehow hosed until you wipe the workspace via Jenkins.

However, if you haven't set the global WC format to 1.7, the situation will recur until you've done so.

Apparently this setting defaults to an SVN 1.4 working copy format, at
least that's what I observe in Jenkins 1.474.

Yes, I had seen that it defaulted to 1.4. I did wonder why. I _thought_ I had changed it to 1.7 and that I still saw the problem, but perhaps I am confused.

Another odd wrinkle to this problem is that apparently in the upgrade from SVN plugin 1.39 to 1.42, the filesystem workspace path changes from $JENKINS_HOME/workspace/$jobname to $JENKINS_HOME/jobs/$jobname/workspace.   So if you are working with the WC directly at the command line, you may be interacting with a directory that Jenkins is no longer using.

[Qazwart]

I just want to clarify: There is never any guarantee that one Subversion client will be working directory compatible with another client.

For example, AnknSVN uses _svn directories instead of .svn directories which means that the standard command line client won't work.

Until Subversion 1.7, this really wasn't too much an issue, users have gotten a bit spoiled since almost all Subversion clients did use the same directory structure. However, that's no longer true, and the situation will get worse as Subversion foreword towards version 2.0.

So a word of warning; be very careful about sharing a Subversion working directory between two different Subversion clients since that has never been officially supported.

--
David Weintraub
Da...@Weintraub.name

On Jul 20, 2012, at 9:30 AM, Carlton Brown <cblis...@gmail.com> wrote: