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.

Folks, my apologies for the long wait. I have produced a build of the Subversion plugin that contains 1.8.x versions.

Since this is a major upgrade of SVNKit, I'm hoping to get some feedback from people before we call it a release. Looking forward to hearing back from you.

Thanks for your tireless work on this project. Out of interest, is svnkit still forked from the official release or have you been able to go back to the main release so that future upgrades will be simpler and less work?

Also, is this plugin set to automatically upgrade the working copy or only when we try to tag or write to the wc?

Downloaded and installed subversion Plug-in 2.3-SNAPSHOT (private-03/11/2014 20:58-kohsuke)

Manage Jenkins > Configure System > Subversion > Subversion Workspace Version > Missing option for 1.8

Also, getting a "Cant install ... from pristine store, because no checksum is recorded for this file" checking out a clean workspace. This does not occur when checking out from the same repo using svnkit 1.8.1.10101 with subclipse 1.10.3 in myeclipse.

Hello guys,

Thank you Kohsuke, for you work on jenkins and specifically on this issue.
Unfortunately, this is not working, at least I can't get it to work.
Here is my output checking out a new working folder, don't know if it helps.

Started by user Pedro de Almeida
Building in workspace H:\util
Checking out a fresh workspace because there's no workspace at H:\util
Cleaning local Directory .
Checking out http://eniac/svn/tecinf/trunk/Util at revision '2014-03-13T10:51:33.873 +0000'
A SVNPostCommit
A SVNPostCommit\SVNPostCommit
A SVNPostCommit\SVNPostCommit\SVNPostCommit.csproj
A SVNPostCommit\SVNPostCommit\SvnHelper.cs
A SVNPostCommit\SVNPostCommit\Program.cs
A SVNPostCommit\SVNPostCommit\Properties
A SVNPostCommit\SVNPostCommit\Properties\AssemblyInfo.cs
ERROR: Failed to check out http://eniac/svn/tecinf/trunk/Util
org.tmatesoft.svn.core.SVNException: svn: E175002: REPORT /svn/tecinf/!svn/vcc/default failed
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361)
at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:710)
at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:334)
at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.runReport(DAVRepository.java:1305)
at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.update(DAVRepository.java:853)
at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.updateInternal(SvnNgAbstractUpdate.java:209)
at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.update(SvnNgAbstractUpdate.java:72)
at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.checkout(SvnNgAbstractUpdate.java:802)
at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:16)
at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:10)
at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20)
at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1149)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
at org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:777)
at hudson.scm.subversion.CheckoutUpdater$1.perform(CheckoutUpdater.java:99)
at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161)
at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:169)
at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:133)
at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161)
at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1029)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1010)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:986)
at hudson.FilePath.act(FilePath.java:914)
at hudson.FilePath.act(FilePath.java:887)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:935)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:870)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1414)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:671)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:580)
at hudson.model.Run.execute(Run.java:1676)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:231)
Caused by: svn: E175002: REPORT /svn/tecinf/!svn/vcc/default failed
at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208)
at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154)
at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97)
... 37 more
Caused by: org.tmatesoft.svn.core.SVNException: svn: E155017: REPORT request failed on '/svn/tecinf/!svn/vcc/default'
svn: E155017: Cant install H:\util\SVNPostCommit\SVNPostCommit\SVNPostCommit.csproj from pristine store, because no checksum is recorded for this file
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382)
... 36 more
Caused by: svn: E155017: REPORT request failed on '/svn/tecinf/!svn/vcc/default'
at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208)
at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154)
at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97)
at org.tmatesoft.svn.core.SVNErrorMessage.wrap(SVNErrorMessage.java:407)
... 38 more
Caused by: svn: E155017: Cant install H:\util\SVNPostCommit\SVNPostCommit\SVNPostCommit.csproj from pristine store, because no checksum is recorded for this file
at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:171)
at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:126)
at org.tmatesoft.svn.core.internal.wc17.SVNWCContext$RunFileInstall.runOperation(SVNWCContext.java:4008)
at org.tmatesoft.svn.core.internal.wc17.SVNWCContext.dispatchWorkItem(SVNWCContext.java:3941)
at org.tmatesoft.svn.core.internal.wc17.SVNWCContext.wqRun(SVNWCContext.java:3929)
at org.tmatesoft.svn.core.internal.wc17.SVNUpdateEditor17.closeDir(SVNUpdateEditor17.java:1169)
at org.tmatesoft.svn.core.internal.wc.SVNCancellableEditor.closeDir(SVNCancellableEditor.java:102)
at org.tmatesoft.svn.core.internal.io.dav.handlers.DAVEditorHandler.endElement(DAVEditorHandler.java:491)
at org.tmatesoft.svn.core.internal.io.dav.handlers.BasicDAVHandler.endElement(BasicDAVHandler.java:103)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.readData(HTTPConnection.java:917)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.readData(HTTPConnection.java:882)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.dispatch(HTTPRequest.java:220)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:480)
... 37 more
java.io.IOException: Failed to check out http://eniac/svn/tecinf/trunk/Util
at hudson.scm.subversion.CheckoutUpdater$1.perform(CheckoutUpdater.java:110)
at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161)
at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:169)
at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:133)
at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161)
at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1029)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1010)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:986)
at hudson.FilePath.act(FilePath.java:914)
at hudson.FilePath.act(FilePath.java:887)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:935)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:870)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1414)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:671)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:580)
at hudson.model.Run.execute(Run.java:1676)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:231)
Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: REPORT /svn/tecinf/!svn/vcc/default failed
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361)
at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:710)
at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:334)
at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.runReport(DAVRepository.java:1305)
at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.update(DAVRepository.java:853)
at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.updateInternal(SvnNgAbstractUpdate.java:209)
at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.update(SvnNgAbstractUpdate.java:72)
at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.checkout(SvnNgAbstractUpdate.java:802)
at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:16)
at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:10)
at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20)
at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1149)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
at org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:777)
at hudson.scm.subversion.CheckoutUpdater$1.perform(CheckoutUpdater.java:99)
... 19 more
Caused by: svn: E175002: REPORT /svn/tecinf/!svn/vcc/default failed
at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208)
at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154)
at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97)
... 37 more
Caused by: org.tmatesoft.svn.core.SVNException: svn: E155017: REPORT request failed on '/svn/tecinf/!svn/vcc/default'
svn: E155017: Cant install H:\util\SVNPostCommit\SVNPostCommit\SVNPostCommit.csproj from pristine store, because no checksum is recorded for this file
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382)
... 36 more
Caused by: svn: E155017: REPORT request failed on '/svn/tecinf/!svn/vcc/default'
at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208)
at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154)
at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97)
at org.tmatesoft.svn.core.SVNErrorMessage.wrap(SVNErrorMessage.java:407)
... 38 more
Caused by: svn: E155017: Cant install H:\util\SVNPostCommit\SVNPostCommit\SVNPostCommit.csproj from pristine store, because no checksum is recorded for this file
at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:171)
at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:126)
at org.tmatesoft.svn.core.internal.wc17.SVNWCContext$RunFileInstall.runOperation(SVNWCContext.java:4008)
at org.tmatesoft.svn.core.internal.wc17.SVNWCContext.dispatchWorkItem(SVNWCContext.java:3941)
at org.tmatesoft.svn.core.internal.wc17.SVNWCContext.wqRun(SVNWCContext.java:3929)
at org.tmatesoft.svn.core.internal.wc17.SVNUpdateEditor17.closeDir(SVNUpdateEditor17.java:1169)
at org.tmatesoft.svn.core.internal.wc.SVNCancellableEditor.closeDir(SVNCancellableEditor.java:102)
at org.tmatesoft.svn.core.internal.io.dav.handlers.DAVEditorHandler.endElement(DAVEditorHandler.java:491)
at org.tmatesoft.svn.core.internal.io.dav.handlers.BasicDAVHandler.endElement(BasicDAVHandler.java:103)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.readData(HTTPConnection.java:917)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.readData(HTTPConnection.java:882)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.dispatch(HTTPRequest.java:220)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:480)
... 37 more
Finished: FAILURE

+1

Hello Kohsuke.

I can confirm problem for version 2.3-SNAPSHOT reported by Pedro.
Maybe there are newer versions available to test?

I ran into this issue as well. As an attempt at a workaround, I added a pre-build step that runs "svn upgrade" and my Jenkins jobs appear to be back in working order. This probably also has a side-effect of requiring a fresh checkout each build.

Same here - can't see 1.8 option in Subversion Workspace Version with 2.3-SNAPSHOT

+1

@Kohsuke...Any updates on fixes to the issues people are experiencing with the 2.3-SNAPSHOT?

I can confirm that there is this issue. Can we help to get this fixed in some ways? Like Coding or something like that?

+1

The issue still seems to be there in version 2.4 which was released on May 16th.

+1

+1
need it,

+1, please!

When this will be implemented?

+1

@Kohsuke since this plugin isn't a high priority for core Jenkins developers, what can the community do to get this moving? Can we rip out svnkit entirely from this plugin and instead rely on svn binaries? At least that way we will not be 18 months behind every svn release.

Although it might not seem important that Jenkins be on the latest release, this is causing a lot of pain to some of us since we have to maintain two completely separate toolchains to support developers (who have moved to 1.8 12 months ago) and our special svn commit process inside Jenkins.

+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?

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

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