+1 for this request.

+1 for this request

+1 for this request.

A quick test after upgrading to 1.51 w/ Jenkins 1.518 (Windows) still results in the following error:

svn: E155036: Please see the 'svn upgrade' command
svn: E155036: The working copy at '\Jenkins\workspace\...'
is too old (format 29) to work with client version '1.8.1 (r1503906)' (expects format 31). You need to upgrade the working copy first.

The machine was rebooted and workspace deleted before test results. Implementing the 'svn upgrade' command with a Windows batch script in the job resolves the issue.

I have SVNVisualServer 2.6 with SVN 1.8, and while able to poll SCM, Jenkins is not able to show the changes or the requests. The console keeps saying that it says: "Checking out a fresh workspace because the workspace is not https://

.com/

/

Cleaning local Directory ." and then "no revision recorded". Is this related to the issue?

Still an issue.
svn: E155036: Please see the 'svn upgrade' command
svn: E155036: The working copy at 'C:\Apps\Jenkins\jobs\xxxx\workspace'
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.

Not sure if the Sponsor This link is being used by anyone else, but I figured I'd give it a try. I'm willing to throw a couple of bucks after the issue anyway: http://www.freedomsponsors.org/core/issue/362/make-subversion-plugin-support-subversion-18

+1 for this request.

+1 for this request

+1 for this request.

BTW...Updating to >= 1.51 of the plugin does allow one to sync a 1.8 repository, but this doesn't help if a) you want to use a newer 1.8 svn client on the target build server and b) you've already upgraded your client and the working copy. The latter results in...
ERROR: svn: E155021: This client is too old to work with the working copy at 'C:\Jenkins' (format '31'). org.tmatesoft.svn.core.SVNException:

Can't believe this issue is not even assigned to anyone?? Since July!

+1 for this request

+1 for this request

I tried using a 1.8.x SVN client with Jenkins. Everything seemed to work fine until I attempted a Maven release which resulted in a failure. Reverting the SVN client to 1.7 resulted in everything working again.
It would be great to get support for 1.8 in place as it has been out for many months now.

Our use case at work is that Jenkins does all the checkout and tagging from and to SVN.

The workspace created by Jenkins Subversion plugin >= 1.51, when checking out of SVN server that is 1.8, is of course in 1.7 working copy format, not 1.8 working copy format. Outside of Jenkins, we don't use any other svn client to access this workspace that is created / checked-out by Jenkins.

Thus, upgrading to Jenkins subversion plug-in 1.51 worked for us.

From the comments here, I see that others are using a different svn client that is a subversion 1.8 client ( which expects a 1.8 working copy format ) on a workspace checked-out by Jenkins subversion plugin >= 1.51 ( which is in 1.7 working copy format ).

What use cases are these ? In these use cases, why can't you use Jenkins subversion plug-in to do all the work related to SVN, including tagging, etc ?

NOTE: I am not a developer for Jenkins or any of the plug-ins. Just asking out of curiosity.

In my case, we are using an SVN server at version 1.6. Upgrading to the newer SVN clients has some associated performance benefits, even when the SVN server is at an older release. Thus the reason I am interested in the newer SVN 1.8 client.
As some my Jenkins jobs perform SVN operations within the build shell step, the Jenkins SVN plugin is obviously not used (i.e. I am using the SVN client installed on the assocaited server). But I managed to get all of that to work using a 1.8 SVN client.

What did not work was performing a Maven release. So it seems that Jenkins must use the SVN client installed on the server directly as opposed to entirely relying on the SVN plugin.

@JohnSalvo...I don't think you can do commits in your scenario. Most of our development is done on developer PCs, but there are circumstances where it is advantageous to get on the build server (where everything is already built) and make changes and commit. (e.g. - NSIS installers... I don't want to build our entire suite of software just to make/test a change to 1 installer). Our commit message must be of a certain format that includes our JIRA number and description at minimum. You can't really automate commits like that, and the SVN administrator required an upgrade to 1.8.3. This breaks the Jenkins plug-in, so I was forced to create my own script to clean the working copy and update. But I've lost my ability to poll SCM and trigger a build.

Whatever the use case, it's just not a good idea to hold such an intregal part of a CI system back. It needs to be kept up to date.

I can add that when using Sonar and the SCM activity plugin, the Sonar analysis fails because the version between SVN server and Jenkins working copy are not compatible.

Jenkins should be up-to-date.

@Tim Bradt, @François Dumont

I am not arguing that Jenkins should not be up-to-date. I completely agree that it should have full support for 1.8. I am not a developer though for Jenkins nor any of its plug-ins .... so I cannot even help at all.

Our use case is that all commits are done from workstations, where everyone is already using Eclipse/Subclipse/svnkit 1.8 or Tortoise SVN 1.8 ..... SVN server at 1.8 ... but Jenkins subversion plug-in is at 1.51 which uses svnkit 1.7.10. Some of our Jenkins jobs also does tagging, etc.

Anything below Jenkins subversion plug-in 1.51 will not allow you to "talk" / poll SVN server 1.8. Hence, I had to wait for subversion plug-in 1.51 ( which uses svnkit 1.7.10 ) before switching the SVN server to 1.8.

Having said that, the Jenkins subversion plugin depends on SVNKIT, and I see that SVNKIT had just came out with 1.8.0-RC1 only 3 days ago, so hopefully, the maintainer of the subversion plug-in will start using svnkit 1.8.0-RC1. Maybe it's just a matter of updating the Subversion plug-in to pull svnkit 1.8.0-RC1 ?

@John

Your use case is certainly more convenient.

I hadn't even looked up the actual SVNKIT, but I see what you mean now about how new it is. Hopefully it won't be long before we see the Jenkins plugin updated.

Added some status to the description...

Please note that svnkit 1.8 final has now been released.

Still unassigned.. fixed in 6 months?

I think it is pointless being narky about it. I'd love for this to be done, but it appears that Jenkins is using a modified svnkit build which might need to be reviewed and merged. I looked through github to see if I could help, but it was not immediately obvious why or how svnkit was forked.

Hopefully whatever patch was required is no longer needed.

+1

+1 today I needed to downgrade to 1.7 because of this

+1, really need to 1.8 support.

+1, need it "yesterday"

+1

+1

+1

+1

+1

+1

+1

Still not assigned, with so many people who want this

+1, waiting

+1

+1

+1

Latest SVNKIT stable version 1.8.3 as of 1/21/14 fully supports 1.8. Hope we see some activity here soon. +10

And you can download it from this official repository:
http://maven.tmatesoft.com/content/repositories/releases/
We look forward to.

+1

+1

+1

+1

There is a merge request now 2 months old to upgrade org.jenkins-ci.svnkit to 1.8.0: https://github.com/jenkinsci/svnkit/pull/2.

But given the Hudson upgrade to 1.8.x just required a change to their pom, I'm hoping we won't need a Jenkins specific SVNKit anymore.

Any news on this?

+1 for this request

+1 (before we have all out projects using Git…)

+1

+1 If it was at least assigned. We can't start to use Jenkins at at all, until this is implemented.

Attached the 2.3-SNAPSHOT build with SVNKit 1.8.4-jenkins-1-SNAPSHOT.