• Icon: Improvement Improvement
    • Resolution: Fixed
    • Icon: Major Major
    • subversion-plugin
    • None
    • All

      Subversion 1.8 is available but the SVN plugin doesn't support it. For example, Configure|Subversion Workspace Version only offers 1.4 thru 1.7.

      https://issues.jenkins-ci.org/browse/JENKINS-18844 is related.


      To summarize this instead of having to browse through all the comments:

      • Talking to a Subversion 1.8 Server should work fine, however the local working copy will still be SVN <=1.7
      • Checking out in Subversion 1.8 Working Copy format does not work, because the version of svnkit that is used in the Subversion plugin (1.7.10) does not support Subversion 1.8 Working Copy

      Things that need to be done to make this work:

      • svnkit 1.8.0 is available and provides support for Subversion 1.8, see http://svnkit.com/download.php
      • Updating to this version and adding "1.8" to the checkbox in the Jenkins Server configuration should be most of what is needed to make it work
      • Unfortunately the Subversion plugin uses a patched version of svnkit, see https://github.com/jenkinsci/svnkit, merging the patches and the newer svnkit requires probably some work, depending on the amount of changes in svnkit upstream
      • As soon as org.jenkins-ci.svnkit is updated to 1.8.x, the Subversion plugin can upgrade to this and use Subversion 1.8 Working Copy format

          [JENKINS-18935] Make Subversion plugin support Subversion 1.8

          I completed PR-103 to work with subversion 1.8. While this worked locally I would like to make sure that this works for other users before performing a new release. Could I get a few volunteers to test this plugin before I perform a release. You can download the subversion.hpi file and install it in the Advanced tab in the Plugin Management page. Please install this in a CONTROLLED TEST ENVIRONMENT as this is still in a pull request and it is not final yet.

          Steven Christou added a comment - I completed PR-103 to work with subversion 1.8. While this worked locally I would like to make sure that this works for other users before performing a new release. Could I get a few volunteers to test this plugin before I perform a release. You can download the subversion.hpi file and install it in the Advanced tab in the Plugin Management page. Please install this in a CONTROLLED TEST ENVIRONMENT as this is still in a pull request and it is not final yet.

          aristedes added a comment -

          I upgraded to "2.5-SNAPSHOT (private-11/08/2014 10:24-jenkins)" and it installed fine. However despite changing the preference to "1.8" it did not upgrade any checked out repository. Other than that it worked fine.

          Will we need to manually destroy all workspaces in order to get them upgraded to 1.8?

          aristedes added a comment - I upgraded to "2.5-SNAPSHOT (private-11/08/2014 10:24-jenkins)" and it installed fine. However despite changing the preference to "1.8" it did not upgrade any checked out repository. Other than that it worked fine. Will we need to manually destroy all workspaces in order to get them upgraded to 1.8?

          aristedes I ran a quick test with the latest released version of this plugin. Performing the switch from one workspace version to another did not upgrade. The only way I was able to upgrade the workspace version was to delete the previous workspace.

          Steven Christou added a comment - aristedes I ran a quick test with the latest released version of this plugin. Performing the switch from one workspace version to another did not upgrade. The only way I was able to upgrade the workspace version was to delete the previous workspace.

          aristedes added a comment -

          OK, if that's the way it is supposed to work, then fine. I deleted the workspace and your upgraded plugin worked perfectly, creating a version 1.8 checkout. So that's quite enough for me to use it in production.

          Thanks!

          aristedes added a comment - OK, if that's the way it is supposed to work, then fine. I deleted the workspace and your upgraded plugin worked perfectly, creating a version 1.8 checkout. So that's quite enough for me to use it in production. Thanks!

          I would recommend that almost all Jenkins job should delete the workspace at the start of the job. This prevents a plethora of issues, including the need to upgrade any files managed by SVN.

          Jason Spotswood added a comment - I would recommend that almost all Jenkins job should delete the workspace at the start of the job. This prevents a plethora of issues, including the need to upgrade any files managed by SVN.

          Shannon Kerr added a comment -

          I humbly disagree, Jason, on the full delete. "Emulate clean checkout..." works perfectly for us. It deletes un-versioned files, deletes modified files, and then runs an svn update, which replaces the deleted modified files as well as updates all of the other repository elements. For us, this saves us a good 5 minutes as our repository is rather large. We typically build on 3 platforms (today serially), so this cuts 15 minutes from our build. I can't imagine what issues we might still be facing by using this option, but at least nothing has bitten us yet.

          That said, I has this plugin ever supported upgrading working copies from one version of Subversion to another? We've always been on 1.7, so it's a test I've never tried. If it hasn't supported this, then I wouldn't expect it to support it now. I think there is a plugin out there that will allow you to add a pre-svn activities step where you could first run the svn upgrade, but I could be wrong about that.

          Shannon Kerr added a comment - I humbly disagree, Jason, on the full delete. "Emulate clean checkout..." works perfectly for us. It deletes un-versioned files, deletes modified files, and then runs an svn update, which replaces the deleted modified files as well as updates all of the other repository elements. For us, this saves us a good 5 minutes as our repository is rather large. We typically build on 3 platforms (today serially), so this cuts 15 minutes from our build. I can't imagine what issues we might still be facing by using this option, but at least nothing has bitten us yet. That said, I has this plugin ever supported upgrading working copies from one version of Subversion to another? We've always been on 1.7, so it's a test I've never tried. If it hasn't supported this, then I wouldn't expect it to support it now. I think there is a plugin out there that will allow you to add a pre-svn activities step where you could first run the svn upgrade, but I could be wrong about that.

          aleksas added a comment - - edited

          I think Jason meant to delete workspace checked out using current 1.7 (or any earlier) svn plugin, and checkout a fresh copy using v1.8. Afterwards "Emulate clean checkout" should work as it did before.

          aleksas added a comment - - edited I think Jason meant to delete workspace checked out using current 1.7 (or any earlier) svn plugin, and checkout a fresh copy using v1.8. Afterwards "Emulate clean checkout" should work as it did before.

          Shannon Kerr added a comment -

          Perhaps, but it is phrased in such a way that it sounds like this should be the proper wait to operate in general. My apologies if I'm still misreading that.

          Shannon Kerr added a comment - Perhaps, but it is phrased in such a way that it sounds like this should be the proper wait to operate in general. My apologies if I'm still misreading that.

          I did mean that in most cases I would expect deletion of the workspace to be the norm. However we do our builds differently in the they do not take long to check out (i.e. we have hundreds of small builds that are only triggered when something changes). As well, when we had used the "Use svn update as much as possible" option, we found that it would often miss updating stuff that and then we wasted heaps of time trying to figure things out. I completely understand that for large checkouts, that deleting the workspace would have a high cost to it.
          That said, the "Emulate clean checkout..." option might be worth checking out as it sounds like a potential winner as long as it is stable. Of course I will only try that after I have upgraded the plugin to use 1.8. Thanks for sharing your comments.

          Jason Spotswood added a comment - I did mean that in most cases I would expect deletion of the workspace to be the norm. However we do our builds differently in the they do not take long to check out (i.e. we have hundreds of small builds that are only triggered when something changes). As well, when we had used the "Use svn update as much as possible" option, we found that it would often miss updating stuff that and then we wasted heaps of time trying to figure things out. I completely understand that for large checkouts, that deleting the workspace would have a high cost to it. That said, the "Emulate clean checkout..." option might be worth checking out as it sounds like a potential winner as long as it is stable. Of course I will only try that after I have upgraded the plugin to use 1.8. Thanks for sharing your comments.

          Tim Fretz added a comment -

          With subversion-2.5-SNAPSHOT.hpi subversion 1.8 is working fine here. Testing was done with Jenkins ver. 1.578 and master and slaves running Ubuntu 14.04.1. My build processes uses externals, "Emulate clean checkout...", and the system svn to interact with the checkout. Can confirm that externals work and Ubuntu 14.04.1 system svn (1.8.8, r1568071) will work with repositories checked out using subversion-2.5-SNAPSHOT.hpi.

          schristou, much appreciated!

          Tim Fretz added a comment - With subversion-2.5-SNAPSHOT.hpi subversion 1.8 is working fine here. Testing was done with Jenkins ver. 1.578 and master and slaves running Ubuntu 14.04.1. My build processes uses externals, "Emulate clean checkout...", and the system svn to interact with the checkout. Can confirm that externals work and Ubuntu 14.04.1 system svn (1.8.8, r1568071) will work with repositories checked out using subversion-2.5-SNAPSHOT.hpi. schristou, much appreciated!

          Tim Bradt added a comment -

          Glad to hear externals work since we have 3 of them.

          @Jason/Shannon - For reasons I won't go into, we also have a large repository which takes 30-40 minutes for a full checkout (we then build pieces of it using custom workspaces), so deleting and checking out for every build would definitely be undesirable. "Emulate clean checkout.." works great for us. If we have to delete the working copy in order to do the upgrade via new checkout, that's fine.

          Tim Bradt added a comment - Glad to hear externals work since we have 3 of them. @Jason/Shannon - For reasons I won't go into, we also have a large repository which takes 30-40 minutes for a full checkout (we then build pieces of it using custom workspaces), so deleting and checking out for every build would definitely be undesirable. "Emulate clean checkout.." works great for us. If we have to delete the working copy in order to do the upgrade via new checkout, that's fine.

          Let's create an improvement issue to add a checkbox for users to force a workspace version (can assign to me).

          Going back to the 1.8 migration, since it looks like multiple people confirm that this works I think we should be safe to merge.

          Steven Christou added a comment - Let's create an improvement issue to add a checkbox for users to force a workspace version (can assign to me). Going back to the 1.8 migration, since it looks like multiple people confirm that this works I think we should be safe to merge.

          Code changed in jenkins
          User: christ66
          Path:
          pom.xml
          src/main/java/hudson/scm/SvnClientManager.java
          src/main/resources/hudson/scm/SubversionSCM/global.jelly
          http://jenkins-ci.org/commit/subversion-plugin/fc8093b49321830a1a55e19910964998998bea8a
          Log:
          JENKINS-18935 Upgrade svnkit library to 1.8.7 and add 1.8 in the global workspace options.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: christ66 Path: pom.xml src/main/java/hudson/scm/SvnClientManager.java src/main/resources/hudson/scm/SubversionSCM/global.jelly http://jenkins-ci.org/commit/subversion-plugin/fc8093b49321830a1a55e19910964998998bea8a Log: JENKINS-18935 Upgrade svnkit library to 1.8.7 and add 1.8 in the global workspace options.

          Code changed in jenkins
          User: Steven Christou
          Path:
          pom.xml
          src/main/java/hudson/scm/SubversionWorkspaceSelector.java
          src/main/java/hudson/scm/SvnClientManager.java
          src/main/java/hudson/scm/subversion/CheckoutUpdater.java
          src/main/resources/hudson/scm/SubversionSCM/global.jelly
          src/test/java/hudson/scm/SVNWorkingCopyTest.java
          http://jenkins-ci.org/commit/subversion-plugin/4a88de9fc6b3eed1b271b65f08541d8bf3a6d8fd
          Log:
          Merge pull request #103 from christ66/JENKINS-18935

          JENKINS-18935 Add support for subversion 1.8 format

          Compare: https://github.com/jenkinsci/subversion-plugin/compare/38af37043e4a...4a88de9fc6b3

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Steven Christou Path: pom.xml src/main/java/hudson/scm/SubversionWorkspaceSelector.java src/main/java/hudson/scm/SvnClientManager.java src/main/java/hudson/scm/subversion/CheckoutUpdater.java src/main/resources/hudson/scm/SubversionSCM/global.jelly src/test/java/hudson/scm/SVNWorkingCopyTest.java http://jenkins-ci.org/commit/subversion-plugin/4a88de9fc6b3eed1b271b65f08541d8bf3a6d8fd Log: Merge pull request #103 from christ66/ JENKINS-18935 JENKINS-18935 Add support for subversion 1.8 format Compare: https://github.com/jenkinsci/subversion-plugin/compare/38af37043e4a...4a88de9fc6b3

          Merged pull request to add 1.8 support. Should be available in next release.

          Steven Christou added a comment - Merged pull request to add 1.8 support. Should be available in next release.

          David Aldrich added a comment - - edited

          Thanks very much for doing this work. When do you expect to make a release? We are eager to try it!

          Or, how can I obtain the snapshot from https://jenkins.ci.cloudbees.com/job/plugins/job/subversion-plugin/458/org.jenkins-ci.plugins$subversion/?

          After upgrading the plugin, if we want to ensure that the working copy is in 1.8 format, should we set Jenkins to do a clean checkout in 1.8 format?

          Meanwhile, will other jobs continue to use 1.7 format by default?

          David Aldrich added a comment - - edited Thanks very much for doing this work. When do you expect to make a release? We are eager to try it! Or, how can I obtain the snapshot from https://jenkins.ci.cloudbees.com/job/plugins/job/subversion-plugin/458/org.jenkins-ci.plugins$subversion/ ? After upgrading the plugin, if we want to ensure that the working copy is in 1.8 format, should we set Jenkins to do a clean checkout in 1.8 format? Meanwhile, will other jobs continue to use 1.7 format by default?

          aristedes added a comment -

          @davida2009 If you want to upgrade a workspace, then the easiest way is to use Jenkins to delete the contents of the workspace entirely. Make sure the general settings has subversion set to 1.8 as the default.

          This upgrade will not change the behaviour of existing workspaces which were checked out in 1.7 mode.

          I've been using this for over a week in production and have had zero problems.

          aristedes added a comment - @davida2009 If you want to upgrade a workspace, then the easiest way is to use Jenkins to delete the contents of the workspace entirely. Make sure the general settings has subversion set to 1.8 as the default. This upgrade will not change the behaviour of existing workspaces which were checked out in 1.7 mode. I've been using this for over a week in production and have had zero problems.

          davida2009 Like mentioned previously, if users would like a "Force workspace format" let's create a new improvement issue for it (previous behavior did not change the format either).

          Snapshot version: https://jenkins.ci.cloudbees.com/job/plugins/job/subversion-plugin/lastSuccessfulBuild/org.jenkins-ci.plugins$subversion/. It looks like we only keep artifacts of the last successful build.

          Steven Christou added a comment - davida2009 Like mentioned previously, if users would like a "Force workspace format" let's create a new improvement issue for it (previous behavior did not change the format either). Snapshot version: https://jenkins.ci.cloudbees.com/job/plugins/job/subversion-plugin/lastSuccessfulBuild/org.jenkins-ci.plugins$subversion/ . It looks like we only keep artifacts of the last successful build.

          Lena Pru added a comment -

          > svnkit 1.8.0 is available and provides support for Subversion 1.8, see http://svnkit.com/download.php
          > Updating to this version and adding "1.8" ...

          I'm sorry, but how do you update svnkit? Unzip org.tmatesoft.svn_1.8.6.standalone.zip into plugins folder? Or somehow manually? (I don't see *.hpi file there)

          Thanks!

          Lena Pru added a comment - > svnkit 1.8.0 is available and provides support for Subversion 1.8, see http://svnkit.com/download.php > Updating to this version and adding "1.8" ... I'm sorry, but how do you update svnkit? Unzip org.tmatesoft.svn_1.8.6.standalone.zip into plugins folder? Or somehow manually? (I don't see *.hpi file there) Thanks!

          David Aldrich added a comment -

          I'm sorry, but how do you update svnkit? Unzip org.tmatesoft.svn_1.8.6.standalone.zip into plugins folder? Or somehow manually? (I don't see *.hpi file there)

          Lena, you don't need to update or use svnkit. Everything necessary is in the Jenkins Subversion plugin. The .hpi file is the plugin.

          David Aldrich added a comment - I'm sorry, but how do you update svnkit? Unzip org.tmatesoft.svn_1.8.6.standalone.zip into plugins folder? Or somehow manually? (I don't see *.hpi file there) Lena, you don't need to update or use svnkit. Everything necessary is in the Jenkins Subversion plugin. The .hpi file is the plugin.

          David Aldrich added a comment -

          I don't understand how the workspace version works.

          I have many Jenkins jobs, all have workspaces in svn 1.7 format (naturally). With the new plugin version, if I set System Configuration > Subversion Workspace Version to 1.8, will the following be true?

          1) Existing 1.7 workspaces will continue to operate fine
          2) New workspaces will be checked out in 1.8 format.

          Am I correct?

          And, to upgrade a workspace from 1.7 to 1.8, do I just select a clean checkout?

          David Aldrich added a comment - I don't understand how the workspace version works. I have many Jenkins jobs, all have workspaces in svn 1.7 format (naturally). With the new plugin version, if I set System Configuration > Subversion Workspace Version to 1.8, will the following be true? 1) Existing 1.7 workspaces will continue to operate fine 2) New workspaces will be checked out in 1.8 format. Am I correct? And, to upgrade a workspace from 1.7 to 1.8, do I just select a clean checkout?

          Lena Pru added a comment -

          My build script does not work in Jenkins. Error message says:

          C:\PAL1>python nightlyBuild.py
          svn: E155036: The working copy at 'C:\PAL1\SVN-PALtrunk'
          is too old (format 29) to work with client version '1.8.3 (r1516576)' (expects format 31). You need to upgrade the working copy first.

          My SVN revision on windows build machine is 1.8.3. It also has Tortoise installed, it's probably not important. I have googled that upgrading SVNKIT will fix this issue. Jenkins Subversion plugin version is 2.4.5. WHAT needs to be done to fix my issue? Please help.

          Lena Pru added a comment - My build script does not work in Jenkins. Error message says: C:\PAL1>python nightlyBuild.py svn: E155036: The working copy at 'C:\PAL1\SVN-PALtrunk' is too old (format 29) to work with client version '1.8.3 (r1516576)' (expects format 31). You need to upgrade the working copy first. My SVN revision on windows build machine is 1.8.3. It also has Tortoise installed, it's probably not important. I have googled that upgrading SVNKIT will fix this issue. Jenkins Subversion plugin version is 2.4.5. WHAT needs to be done to fix my issue? Please help.

          David Aldrich added a comment -

          After upgrading to the new snapshot I noticed two issues:

          1) I set the working copy format to 1.8 and then selected clean checkout in one of my projects. The job, when started, just spun and did not checkout the files. I then deleted the workspace with the o/s and then the job ran fine.

          2) If I run svn status, using a 1.8.10 svn command line client on the cleanly checked out workspace, the report shows that many files are modified. But a diff shows they are not. Perhaps its some svn properties issue, I don't know. TortoiseSVN also indicates modified files.

          This was on a Windows 7 slave.

          David Aldrich added a comment - After upgrading to the new snapshot I noticed two issues: 1) I set the working copy format to 1.8 and then selected clean checkout in one of my projects. The job, when started, just spun and did not checkout the files. I then deleted the workspace with the o/s and then the job ran fine. 2) If I run svn status, using a 1.8.10 svn command line client on the cleanly checked out workspace, the report shows that many files are modified. But a diff shows they are not. Perhaps its some svn properties issue, I don't know. TortoiseSVN also indicates modified files. This was on a Windows 7 slave.

          Peter Berkman added a comment -

          I just upgraded to Jenkins version 1.592 and there is still no "1.8" SVN version in the drop-down in the configuration panel.

          I read through this entire ticket and could find any note of how this was resolved, but it was marked resolved on Nov 17, 2014...

          help please.

          Peter Berkman added a comment - I just upgraded to Jenkins version 1.592 and there is still no "1.8" SVN version in the drop-down in the configuration panel. I read through this entire ticket and could find any note of how this was resolved, but it was marked resolved on Nov 17, 2014... help please.

          Jesse Glick added a comment -

          Jesse Glick added a comment - Install https://jenkins.ci.cloudbees.com/job/plugins/job/subversion-plugin/org.jenkins-ci.plugins$subversion/lastSuccessfulBuild/artifact/org.jenkins-ci.plugins/subversion/2.5-SNAPSHOT/subversion-2.5-SNAPSHOT.hpi if you want to try the fix before the plugin update is released.

          That snapshot fails to use the authentication from the credentials plugin, causing authentication failures. Should I open a new issue or is that a known bug? I'm just trying to get 1.8 to work

          Bayley Gaillard added a comment - That snapshot fails to use the authentication from the credentials plugin, causing authentication failures. Should I open a new issue or is that a known bug? I'm just trying to get 1.8 to work

          Jesse Glick added a comment -

          Should I open a new issue or is that a known bug?

          bgreen if you have to ask the question, the answer is usually “search JIRA for such an open bug, else file a new one (linking to this one as possibly related)”. If you have reason to believe your issue is directly related to this one, for example because you used git bisect to confirm that authentication was broken as a result of this change, then it makes sense to reopen this one because it is not really finished.

          Jesse Glick added a comment - Should I open a new issue or is that a known bug? bgreen if you have to ask the question, the answer is usually “search JIRA for such an open bug, else file a new one (linking to this one as possibly related)”. If you have reason to believe your issue is directly related to this one, for example because you used git bisect to confirm that authentication was broken as a result of this change, then it makes sense to reopen this one because it is not really finished.

          The alternative provided by Jesse Glick is working gracefully to me. Thanks!

          Carlos Eduardo added a comment - The alternative provided by Jesse Glick is working gracefully to me. Thanks!

          Same here too, 2.5 Snapshot is working great

          Nathan Lindshield added a comment - Same here too, 2.5 Snapshot is working great

          J McG added a comment -

          I hope the update will be officially released soon!

          J McG added a comment - I hope the update will be officially released soon!

          Version 2.5 of the subversion plugin has been released which contains this fix.

          Steven Christou added a comment - Version 2.5 of the subversion plugin has been released which contains this fix.

          Henri Gomez added a comment - - edited

          Hi all,

          I updated today Subversion Plugin from 2.4.5 to 2.5 and got errors about old version :

          0:00:34.350 Caused by: org.tmatesoft.svn.core.SVNException: svn: E155021: This client is too old to work with the working copy at
          00:00:34.350 '/var/lib/mycorp/cijenka/builder21/workspace/mirror-centos-repositories-ptx' (format '100').
          00:00:34.350 	at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
          00:00:34.350 	at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
          00:00:34.350 	at org.tmatesoft.svn.core.internal.wc17.db.SVNWCDbRoot.<init>(SVNWCDbRoot.java:104)
          00:00:34.350 	at org.tmatesoft.svn.core.internal.wc17.db.SVNWCDb.init(SVNWCDb.java:242)
          00:00:34.350 	at org.tmatesoft.svn.core.internal.wc17.SVNWCContext.initWC(SVNWCContext.java:4979)
          00:00:34.350 	at org.tmatesoft.svn.core.internal.wc17.SVNWCContext.initializeWC(SVNWCContext.java:4928)
          00:00:34.350 	at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.checkout(SvnNgAbstractUpdate.java:796)
          00:00:34.350 	at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:26)
          00:00:34.350 	at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:11)
          00:00:34.350 	at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20)
          00:00:34.350 	at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21)
          00:00:34.350 	at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1259)
          00:00:34.350 	at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
          00:00:34.350 	at hudson.scm.subversion.CheckoutUpdater$1.perform(CheckoutUpdater.java:115)
          00:00:34.350 	at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:162)
          00:00:34.350 	at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:991)
          00:00:34.350 	at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:972)
          00:00:34.350 	at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:948)
          00:00:34.350 	at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2577)
          00:00:34.350 	at hudson.remoting.UserRequest.perform(UserRequest.java:121)
          00:00:34.350 	at hudson.remoting.UserRequest.perform(UserRequest.java:49)
          00:00:34.350 	at hudson.remoting.Request$2.run(Request.java:324)
          00:00:34.350 	at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
          00:00:34.350 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
          00:00:34.350 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
          00:00:34.350 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
          00:00:34.350 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
          00:00:34.350 	at java.lang.Thread.run(Thread.java:662)
          

          Native Subversion is 1.8.x on master and slave (both openSUSE 13.1).
          I configured Subversion to use 1.7 format by default but it seems .svn has been created in 1.8 format.

          Is it normal ?

          Reverting to Subversion Plugin 2.4.5 fixed problem.
          It seems plugin didn't follow subversion format settings.

          Henri Gomez added a comment - - edited Hi all, I updated today Subversion Plugin from 2.4.5 to 2.5 and got errors about old version : 0:00:34.350 Caused by: org.tmatesoft.svn.core.SVNException: svn: E155021: This client is too old to work with the working copy at 00:00:34.350 '/ var /lib/mycorp/cijenka/builder21/workspace/mirror-centos-repositories-ptx' (format '100' ). 00:00:34.350 at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) 00:00:34.350 at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) 00:00:34.350 at org.tmatesoft.svn.core.internal.wc17.db.SVNWCDbRoot.<init>(SVNWCDbRoot.java:104) 00:00:34.350 at org.tmatesoft.svn.core.internal.wc17.db.SVNWCDb.init(SVNWCDb.java:242) 00:00:34.350 at org.tmatesoft.svn.core.internal.wc17.SVNWCContext.initWC(SVNWCContext.java:4979) 00:00:34.350 at org.tmatesoft.svn.core.internal.wc17.SVNWCContext.initializeWC(SVNWCContext.java:4928) 00:00:34.350 at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.checkout(SvnNgAbstractUpdate.java:796) 00:00:34.350 at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:26) 00:00:34.350 at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:11) 00:00:34.350 at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20) 00:00:34.350 at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21) 00:00:34.350 at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1259) 00:00:34.350 at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) 00:00:34.350 at hudson.scm.subversion.CheckoutUpdater$1.perform(CheckoutUpdater.java:115) 00:00:34.350 at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:162) 00:00:34.350 at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:991) 00:00:34.350 at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:972) 00:00:34.350 at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:948) 00:00:34.350 at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2577) 00:00:34.350 at hudson.remoting.UserRequest.perform(UserRequest.java:121) 00:00:34.350 at hudson.remoting.UserRequest.perform(UserRequest.java:49) 00:00:34.350 at hudson.remoting.Request$2.run(Request.java:324) 00:00:34.350 at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) 00:00:34.350 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) 00:00:34.350 at java.util.concurrent.FutureTask.run(FutureTask.java:138) 00:00:34.350 at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) 00:00:34.350 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) 00:00:34.350 at java.lang. Thread .run( Thread .java:662) Native Subversion is 1.8.x on master and slave (both openSUSE 13.1). I configured Subversion to use 1.7 format by default but it seems .svn has been created in 1.8 format. Is it normal ? Reverting to Subversion Plugin 2.4.5 fixed problem. It seems plugin didn't follow subversion format settings.

          Darren Eyers added a comment -

          Can you try a fresh checkout first so the files are extracted to the disk in the new format?

          Darren Eyers added a comment - Can you try a fresh checkout first so the files are extracted to the disk in the new format?

          Tom Brus added a comment -

          We have the same problem as Henri Gomez above:

          ...This client is too old to work with the working copy...

          But the circumstances are slightly different:

          • I just upgraded the svn plugin from 2.4.5 to 2.5
          • my jobs that do not use a fresh workspace for svn work fine
          • my jobs that use a fresh copy fail as mentioned above
          • svn repos are taken from a dir on the same machine that runs jenkins (file:://...)
          • svn version installed on the machine is 1.7.9
          • in jenkins/configure the Subversion Workspace Version is set to 1.7

          Even completely cleaning the workspace (including removing the .svn dir) does not solve this issue.

          I did not revert to 2.4.5 yet, but I guess that will solve it. I also expect that upgrading the svn version on the machine to 1.8 will solve it.

          When I do an 'svn status' on the dir on the disk from a shell I get the same error message. So my conclusion is that the working dir is created by the plugin as a 1.8 dir and then the locally installed svn (1.7.9) can not deal with that. So the plugin does not seem to listen to the setting Subversion Workspace Version which is set to 1.7.

          Does this help?

          I will go back to 2.4.5 until this is solved.

          Tom Brus added a comment - We have the same problem as Henri Gomez above: ...This client is too old to work with the working copy... But the circumstances are slightly different: I just upgraded the svn plugin from 2.4.5 to 2.5 my jobs that do not use a fresh workspace for svn work fine my jobs that use a fresh copy fail as mentioned above svn repos are taken from a dir on the same machine that runs jenkins ( file::// ...) svn version installed on the machine is 1.7.9 in jenkins/configure the Subversion Workspace Version is set to 1.7 Even completely cleaning the workspace (including removing the .svn dir) does not solve this issue. I did not revert to 2.4.5 yet, but I guess that will solve it. I also expect that upgrading the svn version on the machine to 1.8 will solve it. When I do an 'svn status' on the dir on the disk from a shell I get the same error message. So my conclusion is that the working dir is created by the plugin as a 1.8 dir and then the locally installed svn (1.7.9) can not deal with that. So the plugin does not seem to listen to the setting Subversion Workspace Version which is set to 1.7 . Does this help? I will go back to 2.4.5 until this is solved.

          Henri Gomez added a comment -

          @Darren

          I got errors even after cleaning workspace and using fresh copy.
          Subversion Plugin fetch contents in SVN 1.8 whereas I defined to use SVN 1.7.

          Some part of SVN operation respect 1.7 config but .svn is performed in 1.8

          Henri Gomez added a comment - @Darren I got errors even after cleaning workspace and using fresh copy. Subversion Plugin fetch contents in SVN 1.8 whereas I defined to use SVN 1.7. Some part of SVN operation respect 1.7 config but .svn is performed in 1.8

          Bart van der Schans added a comment - - edited

          – removing comment, as it was misleading (newline in format file doesn't seem to make a difference)

          Bart van der Schans added a comment - - edited – removing comment, as it was misleading (newline in format file doesn't seem to make a difference)

          Looking into the .svn/wc.db version:

          $ sqlite3 .svn/wc.db "PRAGMA user_version"
          100

          And on a correctly 1.8.11 checkout repo:

          $ sqlite3 .svn/wc.db "PRAGMA user_version"
          31

          So it looks like the wrong version gets stored on a clean checkout. I've also tried with svnkit 1.8.7 (1.8.6 is bundled), but that makes no difference.

          Bart van der Schans added a comment - Looking into the .svn/wc.db version: $ sqlite3 .svn/wc.db "PRAGMA user_version" 100 And on a correctly 1.8.11 checkout repo: $ sqlite3 .svn/wc.db "PRAGMA user_version" 31 So it looks like the wrong version gets stored on a clean checkout. I've also tried with svnkit 1.8.7 (1.8.6 is bundled), but that makes no difference.

          Paulo Moreira added a comment - - edited

          Hello,
          I have installed and have no problems with it!

          Windows Node: svn, version 1.8.11
          Linux Node: svn, version 1.8.8

          Jenkins -> configuration -> Subversion = 1.8
          Subversion Plugin = 2.5

          All jobs migrated from 1.7, all do:

          • Always check out a fresh copy
          • Delete workspace before build starts
          • Restart Jenkins

          Paulo Moreira added a comment - - edited Hello, I have installed and have no problems with it! Windows Node: svn, version 1.8.11 Linux Node: svn, version 1.8.8 Jenkins -> configuration -> Subversion = 1.8 Subversion Plugin = 2.5 All jobs migrated from 1.7, all do: Always check out a fresh copy Delete workspace before build starts Restart Jenkins

          Hi Paulo,

          Setting the subversion version to 1.8 solved my format '100' issue! Thanks for sharing. Putting it back to 1.7 also does a correct 1.7 checkout now. Maybe there was some non-initialized value for the version that tricked the plugin in a incorrect checkout?

          Bart

          Bart van der Schans added a comment - Hi Paulo, Setting the subversion version to 1.8 solved my format '100' issue! Thanks for sharing. Putting it back to 1.7 also does a correct 1.7 checkout now. Maybe there was some non-initialized value for the version that tricked the plugin in a incorrect checkout? Bart

          Sarah Sloan added a comment -

          I've updated the plugin to 2.5, and tried checking out in both the 1.7 and 1.8 workspace formats but get the following error. Any ideas? Jenkins version is 1.565.2.
          Thanks,
          Sarah

          FATAL: hudson.scm.SCM.checkout(Lhudson/model/AbstractBuild;Lhudson/Launcher;Lhudson/FilePath;Lhudson/model/BuildListener;Ljava/io/File;)Z
          java.lang.AbstractMethodError: hudson.scm.SCM.checkout(Lhudson/model/AbstractBuild;Lhudson/Launcher;Lhudson/FilePath;Lhudson/model/BuildListener;Ljava/io/File;)Z
          at hudson.model.AbstractProject.checkout(AbstractProject.java:1252)
          at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:615)
          at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
          at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:524)
          at hudson.model.Run.execute(Run.java:1706)
          at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
          at hudson.model.ResourceController.execute(ResourceController.java:88)
          at hudson.model.Executor.run(Executor.java:232)

          Sarah Sloan added a comment - I've updated the plugin to 2.5, and tried checking out in both the 1.7 and 1.8 workspace formats but get the following error. Any ideas? Jenkins version is 1.565.2. Thanks, Sarah FATAL: hudson.scm.SCM.checkout(Lhudson/model/AbstractBuild;Lhudson/Launcher;Lhudson/FilePath;Lhudson/model/BuildListener;Ljava/io/File;)Z java.lang.AbstractMethodError: hudson.scm.SCM.checkout(Lhudson/model/AbstractBuild;Lhudson/Launcher;Lhudson/FilePath;Lhudson/model/BuildListener;Ljava/io/File;)Z at hudson.model.AbstractProject.checkout(AbstractProject.java:1252) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:615) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:524) at hudson.model.Run.execute(Run.java:1706) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:232)

          Sergey Saraev added a comment -

          Hi Sarah,
          Maybe it was because you need to use the сore 1.568 and above:
          https://wiki.jenkins-ci.org/display/JENKINS/Subversion+Plugin

          Sergey Saraev added a comment - Hi Sarah, Maybe it was because you need to use the сore 1.568 and above: https://wiki.jenkins-ci.org/display/JENKINS/Subversion+Plugin

          Sarah Sloan added a comment -

          Ah my bad - thanks!

          Sarah Sloan added a comment - Ah my bad - thanks!

          Hi

          My current Subversion workspace is set to 1.7 but when I attempt to call a Sonar analysis job I get...

          E155036: Please see the 'svn upgrade' command
          svn: E155036: The working copy at 'E:\Jenkins\jobs\AlertEZ - Processor - Analyze\workspace'
          is too old (format 29) to work with client version '1.8.9 (r1591380)' (expects format 31). You need to upgrade the working copy first.

          So to resolve this, I upgraded my Subversion plugin to 2.5 and set my Jenkins Subversion workspace to 1.8.

          This worked a treat but now I am faced with the problem that I can no longer tag using Jenkins. When I attempt to tag a Subversion repository, Jenkins displays the following error...

          ERROR: Publisher hudson.plugins.svn_tag.SvnTagPublisher aborted due to exception
          java.lang.NoSuchMethodError: hudson.scm.SubversionSCM.getRevisionFile(Lhudson/model/AbstractBuild;)Ljava/io/File;
          at hudson.plugins.svn_tag.SvnTagPlugin.parseRevisionFile(SvnTagPlugin.java:242)
          at hudson.plugins.svn_tag.SvnTagPlugin.perform(SvnTagPlugin.java:97)
          at hudson.plugins.svn_tag.SvnTagPublisher.perform(SvnTagPublisher.java:79)
          at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:45)
          at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:761)
          at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:721)
          at hudson.model.Build$BuildExecution.cleanUp(Build.java:192)
          at hudson.model.Run.execute(Run.java:1764)
          at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
          at hudson.model.ResourceController.execute(ResourceController.java:89)
          at hudson.model.Executor.run(Executor.java:240)

          I did try changing my workspace back to version 1.7 but that still displayed the error when tagging the code.

          Note, my Subversion server is on 1.6 but I do not see this as an issue as my 1.8 Tortoise SVN client is backwards compatible with the 1.6 server so I would assume another tool (Subversion plugin in this case) would have no issue either.

          A rollback to version 2.4.5 of the Subversion Plugin resolved the issue but as that version does not support a 1.8 workspace, the Sonar Jenkins job then fails.

          It may be of help if I point out what looks like a similar issue the Subversion Tag plugin has temporarily patched until the Subversion Plugin issue is resolved...
          https://issues.jenkins-ci.org/browse/JENKINS-26217
          I am not using the Subversion Tag plugin so this is of no help to me at present.

          Thanks

          Jonathan Graham added a comment - Hi My current Subversion workspace is set to 1.7 but when I attempt to call a Sonar analysis job I get... E155036: Please see the 'svn upgrade' command svn: E155036: The working copy at 'E:\Jenkins\jobs\AlertEZ - Processor - Analyze\workspace' is too old (format 29) to work with client version '1.8.9 (r1591380)' (expects format 31). You need to upgrade the working copy first. So to resolve this, I upgraded my Subversion plugin to 2.5 and set my Jenkins Subversion workspace to 1.8. This worked a treat but now I am faced with the problem that I can no longer tag using Jenkins. When I attempt to tag a Subversion repository, Jenkins displays the following error... ERROR: Publisher hudson.plugins.svn_tag.SvnTagPublisher aborted due to exception java.lang.NoSuchMethodError: hudson.scm.SubversionSCM.getRevisionFile(Lhudson/model/AbstractBuild;)Ljava/io/File; at hudson.plugins.svn_tag.SvnTagPlugin.parseRevisionFile(SvnTagPlugin.java:242) at hudson.plugins.svn_tag.SvnTagPlugin.perform(SvnTagPlugin.java:97) at hudson.plugins.svn_tag.SvnTagPublisher.perform(SvnTagPublisher.java:79) at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:45) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:761) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:721) at hudson.model.Build$BuildExecution.cleanUp(Build.java:192) at hudson.model.Run.execute(Run.java:1764) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:89) at hudson.model.Executor.run(Executor.java:240) I did try changing my workspace back to version 1.7 but that still displayed the error when tagging the code. Note, my Subversion server is on 1.6 but I do not see this as an issue as my 1.8 Tortoise SVN client is backwards compatible with the 1.6 server so I would assume another tool (Subversion plugin in this case) would have no issue either. A rollback to version 2.4.5 of the Subversion Plugin resolved the issue but as that version does not support a 1.8 workspace, the Sonar Jenkins job then fails. It may be of help if I point out what looks like a similar issue the Subversion Tag plugin has temporarily patched until the Subversion Plugin issue is resolved... https://issues.jenkins-ci.org/browse/JENKINS-26217 I am not using the Subversion Tag plugin so this is of no help to me at present. Thanks

          Karl Theil added a comment -

          this is an other issue im confronted with too: https://issues.jenkins-ci.org/browse/JENKINS-26318

          Karl Theil added a comment - this is an other issue im confronted with too: https://issues.jenkins-ci.org/browse/JENKINS-26318

          Smouch Smouch added a comment -

          Does this:

          Version 2.5 (Jan 2, 2015)
          Replace custom svnkit library in exchange for using the default binaries.
          issue #18935 Upgrade to svn 1.8.
          issue #25241 Upgrade trilead-ssh.

          mean that there is a way to use the hosts version of subversion instead of the Jenkins built-in (plug-in whatever) version ?

          I find the whole topic of subversion support within Jenkins quite confusing.
          I don't understand why Jenkins would ever ship with a plug-in installed by default in such a way that's it's not really a plug-in. I also don't understand why there is a separate plug-in that can be a different version from the one shipped by default.

          I also don't understand why Jenkins would have a subversion plug-in at all. Jenkins is a front end to cron, and of course needs to display results. That there are so many - some conflicting - plug-ins may be considered a strength, but it also means there are simply too many options for failure.

          Jenkins should be should be able to communicate with anything, but not require a "plug-in" or built-in functionality to reproduce (usually incorrectly) or mimic that behavior.

          Smouch Smouch added a comment - Does this: Version 2.5 (Jan 2, 2015) Replace custom svnkit library in exchange for using the default binaries. issue #18935 Upgrade to svn 1.8. issue #25241 Upgrade trilead-ssh. mean that there is a way to use the hosts version of subversion instead of the Jenkins built-in (plug-in whatever) version ? I find the whole topic of subversion support within Jenkins quite confusing. I don't understand why Jenkins would ever ship with a plug-in installed by default in such a way that's it's not really a plug-in. I also don't understand why there is a separate plug-in that can be a different version from the one shipped by default. I also don't understand why Jenkins would have a subversion plug-in at all. Jenkins is a front end to cron, and of course needs to display results. That there are so many - some conflicting - plug-ins may be considered a strength, but it also means there are simply too many options for failure. Jenkins should be should be able to communicate with anything, but not require a "plug-in" or built-in functionality to reproduce (usually incorrectly) or mimic that behavior.

          Daniel Beck added a comment -

          mean that there is a way to use the hosts version of subversion instead of the Jenkins built-in (plug-in whatever) version ?

          No. It just means there's no longer a fork of SVNKit by the Jenkins Project team in use. Subversion plugin does not use the natively installed Subversion client (it doesn't even require one), as it bundles the SVNKit library.

          I don't understand why Jenkins would ever ship with a plug-in installed by default in such a way that's it's not really a plug-in.

          It is. Jenkins works without Subversion Plugin. You can disable it and lose its functionality. It's just bundled and enabled by default for historical reasons (to not break installations upgrading from really ancient versions from before Subversion plugin was detached from core Jenkins – it started life as a part of core Jenkins).

          I also don't understand why there is a separate plug-in that can be a different version from the one shipped by default.

          It's the same plugin, just a newer version of it. Plugins can be updated independently from core versions. The versions of plugins bundled with Jenkins are updated occasionally, but as Subversion 2.0 contained a major, possibly breaking, change to authentication (integration with Credentials plugin) it hasn't been chosen for bundling so far.


          I didn't want to leave your comment unanswered, but please direct any follow-up questions/discussions that aren't directly related to this issue to #jenkins on Freenode, or the jenkinsci-users mailing list. 200 people get an email notification every time you (or anyone) add or edit a comment to this issue.

          Daniel Beck added a comment - mean that there is a way to use the hosts version of subversion instead of the Jenkins built-in (plug-in whatever) version ? No. It just means there's no longer a fork of SVNKit by the Jenkins Project team in use. Subversion plugin does not use the natively installed Subversion client (it doesn't even require one), as it bundles the SVNKit library. I don't understand why Jenkins would ever ship with a plug-in installed by default in such a way that's it's not really a plug-in. It is. Jenkins works without Subversion Plugin. You can disable it and lose its functionality. It's just bundled and enabled by default for historical reasons (to not break installations upgrading from really ancient versions from before Subversion plugin was detached from core Jenkins – it started life as a part of core Jenkins). I also don't understand why there is a separate plug-in that can be a different version from the one shipped by default. It's the same plugin, just a newer version of it. Plugins can be updated independently from core versions. The versions of plugins bundled with Jenkins are updated occasionally, but as Subversion 2.0 contained a major, possibly breaking, change to authentication (integration with Credentials plugin) it hasn't been chosen for bundling so far. I didn't want to leave your comment unanswered, but please direct any follow-up questions/discussions that aren't directly related to this issue to #jenkins on Freenode, or the jenkinsci-users mailing list. 200 people get an email notification every time you (or anyone) add or edit a comment to this issue.

          Andrew Sumner added a comment - - edited

          Is there any reason the the update center in Jenkins doesn't find the 2.5 release? It does find 2.4.5 Running latest LTS Jenkins ver. 1.565.3.

          Andrew Sumner added a comment - - edited Is there any reason the the update center in Jenkins doesn't find the 2.5 release? It does find 2.4.5 Running latest LTS Jenkins ver. 1.565.3.

          Daniel Beck added a comment -

          andrewsumner: 2.5 requires Jenkins 1.568, as you can see on the plugin's wiki page right at the top. 1.565.3 hasn't been "latest LTS" in months, see http://jenkins-ci.org/changelog-stable – the stable update centers just don't offer core upgrades to newer baselines.

          Please ask your next unrelated question on IRC or the jenkinsci-users mailing list. 200 people are notified about every comment created or edited in this issue, so let's keep this on topic (and yes, I realize my comment sends another notification, but I expect that someone would have responded anyway).

          Daniel Beck added a comment - andrewsumner : 2.5 requires Jenkins 1.568, as you can see on the plugin's wiki page right at the top. 1.565.3 hasn't been "latest LTS" in months, see http://jenkins-ci.org/changelog-stable – the stable update centers just don't offer core upgrades to newer baselines. Please ask your next unrelated question on IRC or the jenkinsci-users mailing list. 200 people are notified about every comment created or edited in this issue, so let's keep this on topic (and yes, I realize my comment sends another notification, but I expect that someone would have responded anyway).

          San Jhanjhari added a comment -

          Hi,

          I have got setup Jenkins today with latest version i.e. jenkins-1.611. + SVN 1.8.
          I need to tie up Jenkins to SVN1.8 and seems you could able to do it. Could you please let me know the procedure to install this update to enable SVN 1.8 support?
          I would really appreciate your help on this matter.

          Cheers,
          San

          San Jhanjhari added a comment - Hi, I have got setup Jenkins today with latest version i.e. jenkins-1.611. + SVN 1.8. I need to tie up Jenkins to SVN1.8 and seems you could able to do it. Could you please let me know the procedure to install this update to enable SVN 1.8 support? I would really appreciate your help on this matter. Cheers, San

          Hi, I'm running 1.642.4 and I see the same problem, Subversion 1.8 is not available in the list on Manage Jenkins.
          Any ideas?

          Jonathan Grant added a comment - Hi, I'm running 1.642.4 and I see the same problem, Subversion 1.8 is not available in the list on Manage Jenkins. Any ideas?

          xaviou added a comment -

          Jonathan, which version of Subversion plugin do you have? Make sure you use version 2.5.5 at least.

          xaviou added a comment - Jonathan, which version of Subversion plugin do you have? Make sure you use version 2.5.5 at least.

          Hello Xaviou
          My 1.642.4 came with Subversion plugin 1.54

          I'll install it.

          I can see Jenkins site has 2.5.7 for download. Do you know if there is a reason this isn't included with Jenkins standard full installation?

          Jonathan Grant added a comment - Hello Xaviou My 1.642.4 came with Subversion plugin 1.54 I'll install it. I can see Jenkins site has 2.5.7 for download. Do you know if there is a reason this isn't included with Jenkins standard full installation?

          John Tal added a comment - - edited

          This issue occurs in RHEL 5.11 with Jenkins 2.5 and the SVN plugin 2.5.7.
          Base svn installed on RHEL is svn, version 1.8.15 (r1718365)
          [ERROR] The svn command failed.
          [ERROR] Command output:
          [ERROR] svn: E155036: Please see the 'svn upgrade' command
          svn: E155036: The working copy at '/snipped'
          is too old (format 8) to work with client version '1.8.15 (r1718365)' (expects format 31). You need to upgrade the working copy first.

          This issue resolved by Manage Jenkins -> Configure system -> Subversion Workspace Version update from the default of 1.4 to 1.8 (seems like at least 1.7 should be default)

          John Tal added a comment - - edited This issue occurs in RHEL 5.11 with Jenkins 2.5 and the SVN plugin 2.5.7. Base svn installed on RHEL is svn, version 1.8.15 (r1718365) [ERROR] The svn command failed. [ERROR] Command output: [ERROR] svn: E155036: Please see the 'svn upgrade' command svn: E155036: The working copy at '/snipped' is too old (format 8) to work with client version '1.8.15 (r1718365)' (expects format 31). You need to upgrade the working copy first. This issue resolved by Manage Jenkins -> Configure system -> Subversion Workspace Version update from the default of 1.4 to 1.8 (seems like at least 1.7 should be default)

            schristou Steven Christou
            mmlegra Matt Legrand
            Votes:
            178 Vote for this issue
            Watchers:
            192 Start watching this issue

              Created:
              Updated:
              Resolved: