Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-18935

Make Subversion plugin support Subversion 1.8

    Details

    • Similar Issues:

      Description

      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

        Attachments

          Issue Links

            Activity

            Hide
            fuseboxer Damon Gentry added a comment -

            +1 for this request.

            Show
            fuseboxer Damon Gentry added a comment - +1 for this request.
            Hide
            pgilchrist Preston Gilchrist added a comment -

            +1 for this request

            Show
            pgilchrist Preston Gilchrist added a comment - +1 for this request
            Hide
            mark3000 mark 3000 added a comment -

            +1 for this request.

            Show
            mark3000 mark 3000 added a comment - +1 for this request.
            Hide
            salvojo John Salvo added a comment -

            Just an FYI ... I had this same issue.

            The 1.51 subversion jenkins plugin now uses svnkit 1.7.10, which now allows me to talk to an SVN server running 1.8, which I was not able to do before.

            Show
            salvojo John Salvo added a comment - Just an FYI ... I had this same issue. The 1.51 subversion jenkins plugin now uses svnkit 1.7.10, which now allows me to talk to an SVN server running 1.8, which I was not able to do before.
            Hide
            mark3000 mark 3000 added a comment -

            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.

            Show
            mark3000 mark 3000 added a comment - 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.
            Hide
            samlowery Yishay Lehman added a comment -

            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://

            {XXX}

            .com/

            {Directory}

            /

            {Project}

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

            Show
            samlowery Yishay Lehman added a comment - 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:// {XXX} .com/ {Directory} / {Project} Cleaning local Directory ." and then "no revision recorded". Is this related to the issue?
            Hide
            pthorson Peter Thorson added a comment -

            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

            Show
            pthorson Peter Thorson added a comment - 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
            Hide
            igorama Igor Koyfman added a comment -

            +1 for this request.

            Show
            igorama Igor Koyfman added a comment - +1 for this request.
            Hide
            spratke Brian Spratke added a comment -

            +1 for this request

            Show
            spratke Brian Spratke added a comment - +1 for this request
            Hide
            tpbradt Tim Bradt added a comment -

            +1 for this request.

            Show
            tpbradt Tim Bradt added a comment - +1 for this request.
            Hide
            tpbradt Tim Bradt added a comment -

            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:

            Show
            tpbradt Tim Bradt added a comment - 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:
            Hide
            fdumont François Dumont added a comment - - edited

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

            Show
            fdumont François Dumont added a comment - - edited Can't believe this issue is not even assigned to anyone?? Since July!
            Hide
            chmoser Christoph Moser added a comment -

            +1 for this request

            Show
            chmoser Christoph Moser added a comment - +1 for this request
            Hide
            damienfinck67 Damien Finck added a comment -

            +1 for this request

            Show
            damienfinck67 Damien Finck added a comment - +1 for this request
            Hide
            spots107 Jason Spotswood added a comment -

            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.

            Show
            spots107 Jason Spotswood added a comment - 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.
            Hide
            salvojo John Salvo added a comment -

            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.

            Show
            salvojo John Salvo added a comment - 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.
            Hide
            spots107 Jason Spotswood added a comment -

            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.

            Show
            spots107 Jason Spotswood added a comment - 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.
            Hide
            tpbradt Tim Bradt added a comment -

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

            Show
            tpbradt Tim Bradt added a comment - @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.
            Hide
            fdumont François Dumont added a comment -

            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.

            Show
            fdumont François Dumont added a comment - 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.
            Hide
            salvojo John Salvo added a comment -

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

            Show
            salvojo John Salvo added a comment - @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 ?
            Hide
            tpbradt Tim Bradt added a comment -

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

            Show
            tpbradt Tim Bradt added a comment - @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.
            Hide
            centic centic added a comment -

            Added some status to the description...

            Show
            centic centic added a comment - Added some status to the description...
            Hide
            aristedes aristedes added a comment -

            Please note that svnkit 1.8 final has now been released.

            Show
            aristedes aristedes added a comment - Please note that svnkit 1.8 final has now been released.
            Hide
            fdumont François Dumont added a comment -

            Still unassigned.. fixed in 6 months?

            Show
            fdumont François Dumont added a comment - Still unassigned.. fixed in 6 months?
            Hide
            aristedes aristedes added a comment -

            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.

            Show
            aristedes aristedes added a comment - 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.
            Hide
            david_perez David Pérez added a comment -

            +1

            Show
            david_perez David Pérez added a comment - +1
            Hide
            lvasek Lukáš Vasek added a comment -

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

            Show
            lvasek Lukáš Vasek added a comment - +1 today I needed to downgrade to 1.7 because of this
            Hide
            jknotten John Knottenbelt added a comment -

            +1, really need to 1.8 support.

            Show
            jknotten John Knottenbelt added a comment - +1, really need to 1.8 support.
            Hide
            arseniy_ Arseniy Arseniy added a comment -

            +1, need it "yesterday"

            Show
            arseniy_ Arseniy Arseniy added a comment - +1, need it "yesterday"
            Hide
            dimitkoto Dimitar Sakarov added a comment -

            +1

            Show
            dimitkoto Dimitar Sakarov added a comment - +1
            Hide
            jeebitesh Jeebitesh Kalantri added a comment -

            +1

            Show
            jeebitesh Jeebitesh Kalantri added a comment - +1
            Hide
            jens876 Jens Hirschfeld added a comment -

            +1

            Show
            jens876 Jens Hirschfeld added a comment - +1
            Hide
            ktheil Karl Theil added a comment -

            +1

            Show
            ktheil Karl Theil added a comment - +1
            Hide
            sergey_saraev Sergey Saraev added a comment -

            +1

            Show
            sergey_saraev Sergey Saraev added a comment - +1
            Hide
            wuby Hendrik Stehr added a comment -

            +1

            Show
            wuby Hendrik Stehr added a comment - +1
            Hide
            tpk123 Peter Schmitz added a comment -

            +1

            Show
            tpk123 Peter Schmitz added a comment - +1
            Hide
            fdumont François Dumont added a comment -

            Still not assigned, with so many people who want this

            Show
            fdumont François Dumont added a comment - Still not assigned, with so many people who want this
            Hide
            esukhanov Egor Sukhanov added a comment -

            +1, waiting

            Show
            esukhanov Egor Sukhanov added a comment - +1, waiting
            Hide
            jbehnke Jeff Behnke added a comment -

            +1

            Show
            jbehnke Jeff Behnke added a comment - +1
            Hide
            gregork Gregor K added a comment -

            +1

            Show
            gregork Gregor K added a comment - +1
            Hide
            aleksas aleksas added a comment -

            +1

            Show
            aleksas aleksas added a comment - +1
            Hide
            tpbradt Tim Bradt added a comment -

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

            Show
            tpbradt Tim Bradt added a comment - Latest SVNKIT stable version 1.8.3 as of 1/21/14 fully supports 1.8. Hope we see some activity here soon. +10
            Hide
            sergey_saraev Sergey Saraev added a comment -

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

            Show
            sergey_saraev Sergey Saraev added a comment - And you can download it from this official repository: http://maven.tmatesoft.com/content/repositories/releases/ We look forward to.
            Hide
            xpyct707 Sergey Ryazantsev added a comment -

            +1

            Show
            xpyct707 Sergey Ryazantsev added a comment - +1
            Hide
            eledwaine Tatiana Chernikova added a comment -

            +1

            Show
            eledwaine Tatiana Chernikova added a comment - +1
            Hide
            dpanic Alexey Khmelevskikh added a comment -

            +1

            Show
            dpanic Alexey Khmelevskikh added a comment - +1
            Hide
            benurb Benjamin Urban added a comment -

            +1

            Show
            benurb Benjamin Urban added a comment - +1
            Hide
            pthorson Peter Thorson added a comment -

            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.

            Show
            pthorson Peter Thorson added a comment - 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.
            Hide
            swf Yves Schumann added a comment -

            Any news on this?

            Show
            swf Yves Schumann added a comment - Any news on this?
            Hide
            drothauser Doug Rothauser added a comment -

            +1 for this request

            Show
            drothauser Doug Rothauser added a comment - +1 for this request
            Hide
            trygve Trygve Hardersen added a comment -

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

            Show
            trygve Trygve Hardersen added a comment - +1 (before we have all out projects using Git…)
            Hide
            thomas_runge Thomas Runge added a comment -

            +1

            Show
            thomas_runge Thomas Runge added a comment - +1
            Hide
            jan_wieben Jan Wieben added a comment -

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

            Show
            jan_wieben Jan Wieben added a comment - +1 If it was at least assigned. We can't start to use Jenkins at at all, until this is implemented.
            Hide
            kohsuke Kohsuke Kawaguchi added a comment -

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

            Show
            kohsuke Kohsuke Kawaguchi added a comment - Attached the 2.3-SNAPSHOT build with SVNKit 1.8.4-jenkins-1-SNAPSHOT.
            Hide
            kohsuke Kohsuke Kawaguchi added a comment -

            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.

            Show
            kohsuke Kohsuke Kawaguchi added a comment - 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.
            Hide
            aristedes aristedes added a comment -

            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?

            Show
            aristedes aristedes added a comment - 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?
            Hide
            mikekonikoff Mike Konikoff added a comment - - edited

            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.

            Show
            mikekonikoff Mike Konikoff added a comment - - edited 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.
            Hide
            pmmalmeida Pedro Almeida added a comment -

            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

            Show
            pmmalmeida Pedro Almeida added a comment - 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
            Hide
            utopic_men Utopic Men added a comment -

            +1

            Show
            utopic_men Utopic Men added a comment - +1
            Hide
            sergey_saraev Sergey Saraev added a comment -

            Hello Kohsuke.

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

            Show
            sergey_saraev Sergey Saraev added a comment - Hello Kohsuke. I can confirm problem for version 2.3-SNAPSHOT reported by Pedro. Maybe there are newer versions available to test?
            Hide
            robcollins Rob Collins added a comment -

            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.

            Show
            robcollins Rob Collins added a comment - 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.
            Hide
            tdtappe Heiko Tappe added a comment -

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

            Show
            tdtappe Heiko Tappe added a comment - Same here - can't see 1.8 option in Subversion Workspace Version with 2.3-SNAPSHOT
            Hide
            clonguemart Charles Longuemart added a comment -

            +1

            Show
            clonguemart Charles Longuemart added a comment - +1
            Hide
            tpbradt Tim Bradt added a comment -

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

            Show
            tpbradt Tim Bradt added a comment - @Kohsuke...Any updates on fixes to the issues people are experiencing with the 2.3-SNAPSHOT?
            Hide
            avijendran Aneesh Vijendran added a comment -

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

            Show
            avijendran Aneesh Vijendran added a comment - I can confirm that there is this issue. Can we help to get this fixed in some ways? Like Coding or something like that?
            Hide
            mark3000 mark 3000 added a comment -

            +1

            Show
            mark3000 mark 3000 added a comment - +1
            Hide
            webrat Andreas Sieferlinger added a comment -

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

            Show
            webrat Andreas Sieferlinger added a comment - The issue still seems to be there in version 2.4 which was released on May 16th.
            Hide
            theazyfa michael oullion added a comment -

            +1

            Show
            theazyfa michael oullion added a comment - +1
            Hide
            yuke_p Yuke Priyantoko added a comment -

            +1
            need it,

            Show
            yuke_p Yuke Priyantoko added a comment - +1 need it,
            Hide
            helius Ignacio Sánchez added a comment -

            +1, please!

            Show
            helius Ignacio Sánchez added a comment - +1, please!
            Hide
            imakowski Ireneusz Makowski added a comment -

            When this will be implemented?

            Show
            imakowski Ireneusz Makowski added a comment - When this will be implemented?
            Hide
            sweavo Steve Carter added a comment -

            +1

            Show
            sweavo Steve Carter added a comment - +1
            Hide
            aristedes aristedes added a comment -

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

            Show
            aristedes aristedes added a comment - @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.
            Hide
            frogger3d Wouter de Vries added a comment -

            +1

            Show
            frogger3d Wouter de Vries added a comment - +1
            Hide
            guymestef Guymestef added a comment -

            +1

            Show
            guymestef Guymestef added a comment - +1
            Hide
            noanight Michael K added a comment -

            +1 need it too

            Show
            noanight Michael K added a comment - +1 need it too
            Hide
            integer Kanstantsin Shautsou added a comment -

            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.

            Show
            integer Kanstantsin Shautsou added a comment - 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.
            Hide
            aristedes aristedes added a comment -

            @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?
            Show
            aristedes aristedes added a comment - @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?
            Hide
            swills Steve Wills added a comment -

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

            Show
            swills Steve Wills added a comment - @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?
            Hide
            swills Steve Wills added a comment -

            @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

            Show
            swills Steve Wills added a comment - @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
            Hide
            aristedes aristedes added a comment -

            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.

            Show
            aristedes aristedes added a comment - 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.
            Hide
            aristedes aristedes added a comment -

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

            Show
            aristedes aristedes added a comment - @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.
            Hide
            swills Steve Wills added a comment -

            @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

            Show
            swills Steve Wills added a comment - @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
            Hide
            swills Steve Wills added a comment -

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

            Show
            swills Steve Wills added a comment - @aristedes Well, I guess things could have been sent upstream via their bug tracker, see http://issues.tmatesoft.com/issues/SVNKIT
            Hide
            swills Steve Wills added a comment -

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

            Show
            swills Steve Wills added a comment - @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.
            Hide
            aristedes aristedes added a comment -

            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?

            Show
            aristedes aristedes added a comment - 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?
            Hide
            swills Steve Wills added a comment - - edited

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

            Show
            swills Steve Wills added a comment - - edited @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?
            Hide
            aristedes aristedes added a comment -

            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?

            Show
            aristedes aristedes added a comment - 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?
            Hide
            morpa Josef Andersson added a comment - - edited

            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.

            Show
            morpa Josef Andersson added a comment - - edited 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.
            Hide
            laiw Wing Lai added a comment - - edited

            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
            Show
            laiw Wing Lai added a comment - - edited 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: extract out WEB-INF\plugins\subversion.hpi from jenkins.war you download off http://jenkins-ci.org/ rename to subversion.bak and place it in <jenkins_home>/plugins/ (backup existing subversion.bak first if you like) go to the jenkins plugin manager page and browse to the "installed" tab find the subversion plugin and click on the "downgrade to 1.54" button
            Hide
            davida2009 David Aldrich added a comment -

            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

            Show
            davida2009 David Aldrich added a comment - 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
            Hide
            laiw Wing Lai added a comment -

            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

            Show
            laiw Wing Lai added a comment - 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
            Hide
            aristedes aristedes added a comment -

            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.

            Show
            aristedes aristedes added a comment - 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.
            Hide
            jdege Jeff Dege added a comment -

            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.

            Show
            jdege Jeff Dege added a comment - 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.
            Hide
            kfieldin Kelvin Fielding added a comment -

            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.

            Show
            kfieldin Kelvin Fielding added a comment - 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.
            Hide
            jkelley Josh Kelley added a comment -

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

            Show
            jkelley Josh Kelley added a comment - @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.
            Hide
            jdege Jeff Dege added a comment -

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

            Show
            jdege Jeff Dege added a comment - I just installed the SVN 1.7.14 command-line tools on the build machine.
            Hide
            tpbradt Tim Bradt added a comment -

            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.

            Show
            tpbradt Tim Bradt added a comment - 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.
            Hide
            asheque Saad Rahim added a comment -

            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.

            Show
            asheque Saad Rahim added a comment - 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.
            Hide
            jdege Jeff Dege added a comment -

            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?

            Show
            jdege Jeff Dege added a comment - 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?
            Hide
            asheque Saad Rahim added a comment -

            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.

            Show
            asheque Saad Rahim added a comment - 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.
            Hide
            mark3000 mark 3000 added a comment -

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

            Show
            mark3000 mark 3000 added a comment - If someone would commit to fixing it for a set price, that could possibly make it easier to sell to management.
            Hide
            qhartman Quentin Hartman added a comment -

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

            Show
            qhartman Quentin Hartman added a comment - @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.
            Hide
            bldkfs98 Ben Daniels added a comment -

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

            Show
            bldkfs98 Ben Daniels added a comment - @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?
            Hide
            aristedes aristedes added a comment -

            @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

            Show
            aristedes aristedes added a comment - @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
            Hide
            bldkfs98 Ben Daniels added a comment -

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

            Show
            bldkfs98 Ben Daniels added a comment - @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.
            Hide
            asheque Saad Rahim added a comment -

            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

            Show
            asheque Saad Rahim added a comment - 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
            Hide
            bldkfs98 Ben Daniels added a comment -

            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.

            Show
            bldkfs98 Ben Daniels added a comment - 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.
            Hide
            schristou Steven Christou added a comment -

            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.

            Show
            schristou Steven Christou added a comment - 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.
            Hide
            vlewis Van Lewis added a comment -

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

            Show
            vlewis Van Lewis added a comment - +1 No support for the 1.8 subversion client is affecting the upgrade to ankhsvn and tortoisesvn impacting the use of Visual Studio 2013.
            Hide
            berott B O added a comment - - edited

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

            Show
            berott B O added a comment - - edited +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.
            Hide
            schristou Steven Christou added a comment -

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

            Show
            schristou Steven Christou added a comment - https://github.com/jenkinsci/subversion-plugin/pull/94 removes the modified svnkit from the subversion plugin.
            Hide
            eimers Thomas Eimers added a comment -

            +1

            Show
            eimers Thomas Eimers added a comment - +1
            Hide
            alexmlombardi Alex Lombardi added a comment -

            +15

            Show
            alexmlombardi Alex Lombardi added a comment - +15
            Hide
            integer Kanstantsin Shautsou added a comment -

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

            Show
            integer Kanstantsin Shautsou added a comment - Please, stop flooding. Everybody may send PR with fixed issue.
            Hide
            alexmlombardi Alex Lombardi added a comment -

            Any update on this upgrade yet?

            Show
            alexmlombardi Alex Lombardi added a comment - Any update on this upgrade yet?
            Hide
            qhartman Quentin Hartman added a comment -

            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.

            Show
            qhartman Quentin Hartman added a comment - 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.
            Hide
            imakowski Ireneusz Makowski added a comment -

            Is there any ETA for this?

            Show
            imakowski Ireneusz Makowski added a comment - Is there any ETA for this?
            Hide
            schristou Steven Christou added a comment -

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

            Show
            schristou Steven Christou added a comment - Ireneusz Makowski 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.
            Hide
            aristedes aristedes added a comment -

            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!

            Show
            aristedes aristedes added a comment - 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!
            Hide
            morpa Josef Andersson added a comment -

            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?

            Show
            morpa Josef Andersson added a comment - 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?
            Hide
            schristou Steven Christou added a comment -

            aristedes Thank you! .

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

            Show
            schristou Steven Christou added a comment - aristedes Thank you! . Josef Andersson 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 .
            Hide
            bldkfs98 Ben Daniels added a comment -

            Thanks Steven for your efforts on this!!!

            Show
            bldkfs98 Ben Daniels added a comment - Thanks Steven for your efforts on this!!!
            Hide
            schristou 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.

            Show
            schristou 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.
            Hide
            aristedes 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?

            Show
            aristedes 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?
            Hide
            schristou 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.

            Show
            schristou 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.
            Hide
            aristedes 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!

            Show
            aristedes 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!
            Hide
            spots107 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.

            Show
            spots107 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.
            Hide
            kerrhome 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.

            Show
            kerrhome 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.
            Hide
            aleksas 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.

            Show
            aleksas 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.
            Hide
            kerrhome 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.

            Show
            kerrhome 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.
            Hide
            spots107 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.

            Show
            spots107 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.
            Hide
            odemia 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!

            Show
            odemia 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!
            Hide
            tpbradt 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.

            Show
            tpbradt 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.
            Hide
            schristou 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.

            Show
            schristou 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.
            Hide
            scm_issue_link 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.

            Show
            scm_issue_link 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.
            Hide
            scm_issue_link 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

            Show
            scm_issue_link 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
            Hide
            schristou Steven Christou added a comment -

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

            Show
            schristou Steven Christou added a comment - Merged pull request to add 1.8 support. Should be available in next release.
            Hide
            davida2009 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?

            Show
            davida2009 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?
            Hide
            aristedes 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.

            Show
            aristedes 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.
            Hide
            schristou Steven Christou added a comment -

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

            Show
            schristou Steven Christou added a comment - David Aldrich 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.
            Hide
            lentochka 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!

            Show
            lentochka 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!
            Hide
            davida2009 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.

            Show
            davida2009 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.
            Hide
            davida2009 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?

            Show
            davida2009 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?
            Hide
            lentochka 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.

            Show
            lentochka 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.
            Hide
            davida2009 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.

            Show
            davida2009 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.
            Hide
            peterberkman 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.

            Show
            peterberkman 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.
            Show
            jglick 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.
            Hide
            bgreen 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

            Show
            bgreen 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
            Hide
            jglick Jesse Glick added a comment -

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

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

            Show
            jglick Jesse Glick added a comment - Should I open a new issue or is that a known bug? Bayley Gaillard 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.
            Hide
            carlospauluk Carlos Eduardo added a comment -

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

            Show
            carlospauluk Carlos Eduardo added a comment - The alternative provided by Jesse Glick is working gracefully to me. Thanks!
            Hide
            nbl9999 Nathan Lindshield added a comment -

            Same here too, 2.5 Snapshot is working great

            Show
            nbl9999 Nathan Lindshield added a comment - Same here too, 2.5 Snapshot is working great
            Hide
            jmmcg1 J McG added a comment -

            I hope the update will be officially released soon!

            Show
            jmmcg1 J McG added a comment - I hope the update will be officially released soon!
            Hide
            schristou Steven Christou added a comment -

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

            Show
            schristou Steven Christou added a comment - Version 2.5 of the subversion plugin has been released which contains this fix.
            Hide
            hgomez 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.

            Show
            hgomez 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.
            Hide
            dseyers Darren Eyers added a comment -

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

            Show
            dseyers Darren Eyers added a comment - Can you try a fresh checkout first so the files are extracted to the disk in the new format?
            Hide
            tombrus 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.

            Show
            tombrus 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.
            Hide
            hgomez 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

            Show
            hgomez 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
            Hide
            schans 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)

            Show
            schans 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)
            Hide
            schans 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.

            Show
            schans 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.
            Hide
            pmesteves 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
            Show
            pmesteves 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
            Hide
            schans 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

            Show
            schans 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
            Hide
            srh_sloan 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)

            Show
            srh_sloan 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)
            Hide
            sergey_saraev 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

            Show
            sergey_saraev 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
            Hide
            srh_sloan Sarah Sloan added a comment -

            Ah my bad - thanks!

            Show
            srh_sloan Sarah Sloan added a comment - Ah my bad - thanks!
            Hide
            jonathangrm 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

            Show
            jonathangrm 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
            Hide
            ktheil Karl Theil added a comment -

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

            Show
            ktheil Karl Theil added a comment - this is an other issue im confronted with too: https://issues.jenkins-ci.org/browse/JENKINS-26318
            Hide
            smouch 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.

            Show
            smouch 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.
            Hide
            danielbeck 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.

            Show
            danielbeck 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.
            Hide
            andrewsumner 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.

            Show
            andrewsumner 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.
            Hide
            danielbeck Daniel Beck added a comment -

            Andrew Sumner: 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).

            Show
            danielbeck Daniel Beck added a comment - Andrew Sumner : 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).
            Hide
            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

            Show
            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
            Hide
            jgrant 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?

            Show
            jgrant 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?
            Hide
            xaviou xaviou added a comment -

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

            Show
            xaviou xaviou added a comment - Jonathan, which version of Subversion plugin do you have? Make sure you use version 2.5.5 at least.
            Hide
            jgrant 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?

            Show
            jgrant 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?
            Hide
            bluejaguar777 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)

            Show
            bluejaguar777 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)

              People

              • Assignee:
                schristou Steven Christou
                Reporter:
                mmlegra Matt Legrand
              • Votes:
                178 Vote for this issue
                Watchers:
                193 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: