+1

+1

+1 need it too

Please, don't spam with +1 messages, there is a vote button.
@aristedes community can do PR with fixes and open separate bug with linking issues to this root issue.

@Kanstantsin

I think you are just seeing frustration from people who don't know how else to assist. At any rate, my question is not "can we fork this plugin". Obviously anyone can do that. The real problems here are:

• svnkit has been modified in some way for Jenkins. My guess is that that's the root cause of the problem with upgrading. There is no documentation for this modification that I could find and when I tried to diff the modified version against the original svnkit I found it hard to know what versions to diff against.

• this happens every single time svn is upgraded. svnkit lags about 6 months behind svn itself, and Jenkins sometimes lags another 12 months behind that.

• if I put in the hours to rip out svnkit and replace it with calls to command line svn or javahl, will that change be accepted back into the project? I have no interest in maintaining my own fork of this plugin forever.

• alternatively, could someone document why svnkit needs to be modified so that either someone else can pick up the work or figure a way to use plain vanilla svnkit? I am guessing that this is the bulk of the work needed each time svnkit updates.

• finally, although Kohsuke was trying to help by getting 90% of the changes done, this has effectively stopped anyone else working on the problem since we are all waiting for the last 10%. Do we continue to wait or should someone else start again?

@aristedes I like how you're thinking, but I can't find the modified version of svnkit. I looked at the plugin source (https://github.com/jenkinsci/subversion-plugin) but didn't see it. Where is it?

@aristedes Sorry, I should have looked more, I found it. https://github.com/jenkinsci/svnkit seems to be it and it seems to be based on 1.7.10. In fact, the diff doesn't seem very large. See https://gist.github.com/anonymous/a9feffebed6d4ee1fe95 for what I believe is the set of changes between upstream SVNKit 1.7.10 and svnkit-1.7.10-jenkins-1

From the pom file:

<dependency>
      <groupId>org.jenkins-ci.svnkit</groupId>
      <artifactId>svnkit</artifactId>
      <version>1.7.10-jenkins-1</version>
</dependency>

Which I think points to: https://github.com/jenkinsci/svnkit More recent changes can be seen here https://github.com/jenkinsci/svnkit/commits/master-1.8.x but this is 40 commits behind master, so I'm not sure what exactly needs merging.

@steve

That's helpful. Do you want to try that again but against the master-1.8.x branch and svnkit 1.8. Maybe we can figure out what is going on. There seems to be a bunch of things around exception handling (perhaps to get better exceptions into Jenkins logs) and some things to do with authentication. There are also a bunch of whitespace (and import) changes that have no effect.

Were these changes ever submitted to svnkit for merging? I don't know where to start looking for such a pull request.

@aristedes that's where things get ugly. The diff is over 6k lines. https://gist.github.com/anonymous/dd46cb35b3cf2bf59cb4 But most of it seems to be stuff that upstream has changed that the jenkins version hasn't pulled in yet. As far as pushing the changes back upstream, the svnkit folks seem to (naturally) keep their stuff in svn and don't give a hint on where to send upstream changes on their site. See http://svnkit.com

@aristedes Well, I guess things could have been sent upstream via their bug tracker, see http://issues.tmatesoft.com/issues/SVNKIT

@aristedes Sorry, that diff was wrong, it was against the upstream trunk, not the 1.8.5 branch. Regardless, it should have been against 1.8.4, which seems to be where the master-1.8.4 branch in git is. So the diff would be https://gist.github.com/anonymous/084284d944b2be0e3ecc which doesn't actually look like that much.

Looks like svnkit-jenkins is 1.8.3 given this modified-1.8/svnkit/src/main/java/org/tmatesoft/svn/util/Version.java So perhaps the diff to 1.8.3 is even less.

Once you get past the changes to imports, gitignore, pom, etc. then the changes don't look significant. I wonder what is needed to remove them entirely? I assume there was a good reason for them originally. Perhaps we need to find the commits one at a time. For example, here is one:

https://github.com/jenkinsci/svnkit/commit/e48e3376b1a6b8b923a313f160456529c67f7dd1

But the commit message doesn't tell us anything useful about WHY this was done. What problem was solved? Maybe something to do with sending configuration to a Jenkins slave?

@aristedes the thing that made me think it was 1.8.4 was the diff for build.gradle. Also, diffing against 1.8.3 produces a larger diff than anything so far, with lots of changes to wc stuff. So I think 1.8.4 is right, tho perhaps not everything from upstream was merged. You're right about that e48e3376 diff. I did a quick pass through trying to find the source of the diffs and the notes I came up with are here https://gist.github.com/bafc1445c7ed9e1855a2 Maybe that's helpful. Certainly the changes look useful in some places, so I'm not sure using the stock svnkit would work. Perhaps the right way to go is to fork the forked version, pull in the rest of the upstream changes and test that?

I started adding in commit comments: https://gist.github.com/ari/f1fc75c22b92ab17a73d

So far, many of the commits are around exception reporting, which might be just a cosmetic thing and could be discarded. Another commit is marked as fixed upstream. One the commits was a workaround for a problem in a fork of a Java clone of SSH. Where do we even begin unravelling all this?

We just upgraded our internal systems, and I can't believe Jenkins, more than one year after it was released, doesn't have full support for Subversion 1.8.This should really be a high priority issue now, hope someone stands up to be a hero and fix the issue. It seems to be the second most popular issue regarding number of votes.

We are waiting for a fix to this as well but I wonder if people is aware of a workaround I've been using in my company. The older subversion plugin (1.54) which is the default version from the latest jenkins.war has no issues checking out code from a 1.8 repository. The check out in Jenkin's workspace will then be in 1.6 client format which doesn't cause any issues.

If you've upgraded the plugin already then just:

1. extract out WEB-INF\plugins\subversion.hpi from jenkins.war you download off http://jenkins-ci.org/
2. rename to subversion.bak and place it in <jenkins_home>/plugins/ (backup existing subversion.bak first if you like)
3. go to the jenkins plugin manager page and browse to the "installed" tab
4. find the subversion plugin and click on the "downgrade to 1.54" button

Hi Wing

The issue is not being able to check out from a svn 1.8 repo. The current client can do that. The issue is that the current client creates a 1.7 working copy, which is incompatible with any 1.8 client also installed on the local machine.

BR

David

Ah ok, when I first stumbled into here the issue I was having was that the latest plugin can't even check out code from a subversion 1.8 server. Think things have changed to also support 1.8 client version. Just ignore my post

Also we have a gradle toolchain that performs svn operations as part of the build process. And because svnkit cannot operate on a 1.7 repository this is holding back all our users from upgrading svn on their desktops.

I did spend some time looking at the work Steve Wills contributed, but I haven't had the time to try and pull apart the long and undocumented set of changes hacked over the top of svnkit. I don't know if someone else might be able to do that, but I fear that without a contributor willing to pull this apart, we are likely to be stuck on 1.7 indefinitely.

This just bit me.

We use SubWCRev as a part of our build process, to inject the SVN revision number into the project's version number. (Generating Properties\AssemblyInfo.cs from a template.)

I've just failed at moving our first project that does this into Jenkins, because our build machine has SVN 1.8.3 installed, and it can't read the SVN 1.7 workspace that Jenkins' SVN plugin creates.

I found if you put a pre build step of svn upgrade. And make the svn always refresh then it works. Not pretty but hey it works.

@Jeff Dege - We do something similar but were able to work around this by updating our script to check for the SVN_REVISION environment variable (see the Jenkins Subversion plugin page) and, if that's present, use that instead of trying to check the revision itself.

I just installed the SVN 1.7.14 command-line tools on the build machine.

And there you have it @Jeff Dege...exactly what we're doing on our build servers. After a year, I'm tired of waiting for Jenkins to get current so succumbing to a downgrade of SVN clients on our build servers. I had upgraded them to 1.8 and made my own clean checkout script, but that means no Poll SCM build trigger.

It is time for the Jenkins project to either formally issue an end of life statement for the subversion plugin or commit to a timeline to fixing the plugin. If this is the end of Jenkins and Subversion, I can move on and investigate if Git fits our needs. This uncertainty is costing our business the productivity and features associated with running an up to date version control software.

I share in the frustration, that Jenkins hasn't current with svnkit. But for all those who are insisting that the Jenkins team do something about this, there's a "Sponsor this" link in the top right corner of the page for this issue.

Instead of complaining to us, who agree with you, why don't you suggest to your bosses that they could improve the software and gain some goodwill in the community?

It is not so easy to gain approval to pay for free software. If Jenkins charged $1000 a year to use, I would have a PO signed tomorrow. We discussed sponsoring here, unlikely anything less than $1000 would entice the developers to prioritize this. Management would never approve that sum for a donation, accounting wouldn't know how to classify it and the auditors would wonder what it is. That is the case with many small businesses. Perhaps a year after svn 1.9 is release, I could convince them to take the effort.

If someone would commit to fixing it for a set price, that could possibly make it easier to sell to management.

@Saad Rahim - I've had luck coding such things as a "Computer Consulting Fee" at other organizations. The accountants knew how to handle it, and management thought it accurately captured the spirit of the expenditure. If you are working for a governmental agency they likely already have an accounting code for such things. The one time I did this, I engaged the developers before hand to ensure that our problem was likely to be solved in a timely manner, and we paid the "fee" half up front and half after delivery. It worked out well for everyone, and the items we needed materialized in just a couple weeks.

@Jeff @Saad - I've just run into this issue as well since we have a planned upgrade from SVN 1.6 to the latest (1.8) and now I'm finding that our Jenkins server could potentially derail that and force us to only move up to 1.7

We rely heavily on SCM polling among other features, and it's quite frustrating that there is no compatibility with 1.8. There are still plenty of folks using Subversion that need this functionality.

I really don't want to introduce pre-build steps of running SVN_UPGRADE and doing full checkouts.

If everyone here is onboard, do we know who is developing the Subversion plugin to ask them if 1.8 support is on the roadmap for their particular version of SVNKit?

@Ben I think the whole problem is that no one is working on this plugin, so someone needs to step forward with the time available to do it.

In my opinion, the job here is not to "upgrade svnkit". That part is trivial. The real work is to unravel the customisations made to svnkit and remove them from this project, finding other ways to solve the problems they were put in there to solve. Once we are using plain vanilla svnkit, the rest is simple.

The problem is that in my cursory review it wasn't obvious why the svnkit fork was made. Some were clearer (like making some classes serializable presumably to handle Jenkins slaves) but others not. It will need some time to review if the original person who made those changes is not available to help.

Here is the beginning of the analysis of the changes: https://gist.github.com/ari/f1fc75c22b92ab17a73d

@Aristedes Thanks Ari, that clears up some of the confusion I was having. Hopefully there is enough need from the community to rally support around removing those customizations from SVNKit in order to allow the Jenkins Subversion Plugin to more easily adapt to future SVN releases.

Hudson seems to have upgraded to svn 1.8. Are the plugins close enough to switch to the Hudson version?

From http://wiki.hudson-ci.org/display/HUDSON/Subversion+Plugin

Change Log

Version 2.3.10 (Aug 5, 2014)
•Upgrade to svnkit 1.8.5
•438400 - 1.8 Is not a permitted Subversion Workspace Version in Manage Hudson
•439300 - Selecting "Subversion Workspace Version" 1.7 checks-out workspace as 1.8

Version 2.3.9 (June 26, 2014)
•Upgrade to svnkit 1.8.3-1
•Add possibility to ignore notifications from post-commit hooks

Interesting. I wonder whether the Hudson version would work, and if it has the same customizations the Jenkins SVNKit does. If it was a viable alternative (or a good starting point to adapt the Jenkins plugin) it could save a lot of work.

Hudson subversion plugin can't be migrated to Jenkins easily without breaking a lot of jobs. I was the one who migrated the hudson subversion plugin to not use the modified svnkit. I created a PR a few months ago to try migrating to the new svnkit: https://github.com/jenkinsci/subversion-plugin/pull/76. I closed it because I messed up the PR. I will re-create the PR.

+1 No support for the 1.8 subversion client is affecting the upgrade to ankhsvn and tortoisesvn impacting the use of Visual Studio 2013.

+1 No support for 1.8 affect us because we deploy with jenkis using svn checkouts. it's a pain that working directory must stay at 1.7. HURRY, to give us 1.8, please.

Alternative: drop svn kit and use a external svn cli client instead.

https://github.com/jenkinsci/subversion-plugin/pull/94 removes the modified svnkit from the subversion plugin.

+1

+15

Please, stop flooding. Everybody may send PR with fixed issue.

Any update on this upgrade yet?

To work around this problem I've ended up installing svn 1.7 and 1.8 clients on all my build boxes and modified my scripts to use $svn and $old_svn variables pointing at the correct binaries as needed. It was a hassle, but not a huge one, and certainly better than living with a broken system while waiting for this to get resolved.

Is there any ETA for this?

imakowski Sorry I was on vacation part of last week, however I managed to fix my PR on my computer at home (forgot to push). I will finish this PR and create a new one for the migration.

For all those people eagerly awaiting an outcome on this task, I can report that a commit was pushed to the main github repo about 24 hours ago which removes the customised svnkit and replaces it with the standard library.

This was the main stumbling block that prevented svnkit from being upgraded (and in fact was the reason why it was such a huge task to move forward every time svnkit was upgraded). Now I think it is just about testing and then upgrading svnkit to 1.8 and more testing, so hopefully this will happen soon.

Steve Christou, you have the thanks of everyone here!

If the problem is fixed, Steve Christou, you're our hero! Out of curiosity, why was the old svnkit so patched, if it wasn't needed?

aristedes Thank you! .

morpa Thanks. There were a lot of custom code in the old svnkit mostly for other plugins like blamesvn plugin, and svnmerge plugin. Before any new release could be made, I need to fix/release these plugins first.

I have a WIP PR for svn 1.8: PR 103.

Thanks Steven for your efforts on this!!!

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.

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.

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.

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.

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.

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!

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.

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

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

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?

@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.

> 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, you don't need to update or use svnkit. Everything necessary is in the Jenkins Subversion plugin. The .hpi file is the plugin.

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?

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.

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.

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.

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

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!

Same here too, 2.5 Snapshot is working great

I hope the update will be officially released soon!

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

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.

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

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.

@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

– 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.

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

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)

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

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

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

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.

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.

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.

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).

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, which version of Subversion plugin do you have? Make sure you use version 2.5.5 at least.