[JENKINS-18935] Make Subversion plugin support Subversion 1.8

mark 3000 added a comment - 2013-09-24 19:10

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.

mark 3000 added a comment - 2013-09-24 19:10 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.

Yishay Lehman added a comment - 2013-10-01 09:32

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?

Yishay Lehman added a comment - 2013-10-01 09:32 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?

Peter Thorson added a comment - 2013-10-03 23:59

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

Peter Thorson added a comment - 2013-10-03 23:59 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

Igor Koyfman added a comment - 2013-10-26 23:48

+1 for this request.

Igor Koyfman added a comment - 2013-10-26 23:48 +1 for this request.

Brian Spratke added a comment - 2013-10-30 18:27

+1 for this request

Brian Spratke added a comment - 2013-10-30 18:27 +1 for this request

Tim Bradt added a comment - 2013-10-30 19:17

+1 for this request.

Tim Bradt added a comment - 2013-10-30 19:17 +1 for this request.

Tim Bradt added a comment - 2013-10-31 01:50

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:

Tim Bradt added a comment - 2013-10-31 01:50 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:

François Dumont added a comment - 2013-11-04 18:29 - edited

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

François Dumont added a comment - 2013-11-04 18:29 - edited Can't believe this issue is not even assigned to anyone?? Since July!

Christoph Moser added a comment - 2013-11-05 14:43

+1 for this request

Christoph Moser added a comment - 2013-11-05 14:43 +1 for this request

Damien Finck added a comment - 2013-11-05 15:02

+1 for this request

Damien Finck added a comment - 2013-11-05 15:02 +1 for this request

Jason Spotswood added a comment - 2013-11-06 11:54

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.

Jason Spotswood added a comment - 2013-11-06 11:54 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.

John Salvo added a comment - 2013-11-07 00:15

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.

John Salvo added a comment - 2013-11-07 00:15 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.

Jason Spotswood added a comment - 2013-11-07 01:25

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.

Jason Spotswood added a comment - 2013-11-07 01:25 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.

Tim Bradt added a comment - 2013-11-07 12:57

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

Tim Bradt added a comment - 2013-11-07 12:57 @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.

François Dumont added a comment - 2013-11-07 13:28

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.

François Dumont added a comment - 2013-11-07 13:28 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.

John Salvo added a comment - 2013-11-07 22:51

@Tim Bradt, @François Dumont

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

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

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

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

John Salvo added a comment - 2013-11-07 22:51 @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 ?

Tim Bradt added a comment - 2013-11-08 02:24

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

Tim Bradt added a comment - 2013-11-08 02:24 @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.

centic added a comment - 2013-11-25 20:21

Added some status to the description...

centic added a comment - 2013-11-25 20:21 Added some status to the description...

aristedes added a comment - 2013-11-29 06:50

Please note that svnkit 1.8 final has now been released.

aristedes added a comment - 2013-11-29 06:50 Please note that svnkit 1.8 final has now been released.

François Dumont added a comment - 2013-11-29 07:40

Still unassigned.. fixed in 6 months?

François Dumont added a comment - 2013-11-29 07:40 Still unassigned.. fixed in 6 months?

aristedes added a comment - 2013-12-02 06:13

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.

aristedes added a comment - 2013-12-02 06:13 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.

David Pérez added a comment - 2013-12-03 10:39

+1

David Pérez added a comment - 2013-12-03 10:39 +1

Lukáš Vasek added a comment - 2013-12-03 10:42

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

Lukáš Vasek added a comment - 2013-12-03 10:42 +1 today I needed to downgrade to 1.7 because of this

John Knottenbelt added a comment - 2013-12-06 11:38

+1, really need to 1.8 support.

John Knottenbelt added a comment - 2013-12-06 11:38 +1, really need to 1.8 support.

Arseniy Arseniy added a comment - 2013-12-16 09:36

+1, need it "yesterday"

Arseniy Arseniy added a comment - 2013-12-16 09:36 +1, need it "yesterday"

Dimitar Sakarov added a comment - 2014-01-09 13:50

+1

Dimitar Sakarov added a comment - 2014-01-09 13:50 +1

Jeebitesh Kalantri added a comment - 2014-01-13 10:31

+1

Jeebitesh Kalantri added a comment - 2014-01-13 10:31 +1

Jens Hirschfeld added a comment - 2014-01-13 10:35

+1

Jens Hirschfeld added a comment - 2014-01-13 10:35 +1

Karl Theil added a comment - 2014-01-17 15:30

+1

Karl Theil added a comment - 2014-01-17 15:30 +1

Sergey Saraev added a comment - 2014-01-31 12:35

+1

Sergey Saraev added a comment - 2014-01-31 12:35 +1

Hendrik Stehr added a comment - 2014-01-31 15:18

+1

Hendrik Stehr added a comment - 2014-01-31 15:18 +1

Peter Schmitz added a comment - 2014-01-31 15:21

+1

Peter Schmitz added a comment - 2014-01-31 15:21 +1

François Dumont added a comment - 2014-01-31 15:57

Still not assigned, with so many people who want this

François Dumont added a comment - 2014-01-31 15:57 Still not assigned, with so many people who want this

Egor Sukhanov added a comment - 2014-01-31 16:07

+1, waiting

Egor Sukhanov added a comment - 2014-01-31 16:07 +1, waiting

Jeff Behnke added a comment - 2014-01-31 16:24

+1

Jeff Behnke added a comment - 2014-01-31 16:24 +1

Gregor K added a comment - 2014-01-31 17:36

+1

Gregor K added a comment - 2014-01-31 17:36 +1

aleksas added a comment - 2014-02-03 09:20

+1

aleksas added a comment - 2014-02-03 09:20 +1

Tim Bradt added a comment - 2014-02-03 12:56

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

Tim Bradt added a comment - 2014-02-03 12:56 Latest SVNKIT stable version 1.8.3 as of 1/21/14 fully supports 1.8. Hope we see some activity here soon. +10

Sergey Saraev added a comment - 2014-02-03 13:47

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

Sergey Saraev added a comment - 2014-02-03 13:47 And you can download it from this official repository: http://maven.tmatesoft.com/content/repositories/releases/ We look forward to.

Sergey Ryazantsev added a comment - 2014-02-03 13:58

+1

Sergey Ryazantsev added a comment - 2014-02-03 13:58 +1

Tatiana Chernikova added a comment - 2014-02-03 14:03

+1

Tatiana Chernikova added a comment - 2014-02-03 14:03 +1

Alexey Khmelevskikh added a comment - 2014-02-03 14:07

+1

Alexey Khmelevskikh added a comment - 2014-02-03 14:07 +1

Benjamin Urban added a comment - 2014-02-04 08:12

+1

Benjamin Urban added a comment - 2014-02-04 08:12 +1

Peter Thorson added a comment - 2014-02-04 18:21

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.

Peter Thorson added a comment - 2014-02-04 18:21 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.

Yves Schumann added a comment - 2014-02-05 16:06

Any news on this?

Yves Schumann added a comment - 2014-02-05 16:06 Any news on this?

Doug Rothauser added a comment - 2014-02-12 12:30

+1 for this request

Doug Rothauser added a comment - 2014-02-12 12:30 +1 for this request

Trygve Hardersen added a comment - 2014-02-12 22:42

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

Trygve Hardersen added a comment - 2014-02-12 22:42 +1 (before we have all out projects using Git…)

Thomas Runge added a comment - 2014-03-03 13:13

+1

Thomas Runge added a comment - 2014-03-03 13:13 +1

Jan Wieben added a comment - 2014-03-10 10:45

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

Jan Wieben added a comment - 2014-03-10 10:45 +1 If it was at least assigned. We can't start to use Jenkins at at all, until this is implemented.

Kohsuke Kawaguchi added a comment - 2014-03-12 03:59

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

Kohsuke Kawaguchi added a comment - 2014-03-12 03:59 Attached the 2.3-SNAPSHOT build with SVNKit 1.8.4-jenkins-1-SNAPSHOT.

Kohsuke Kawaguchi added a comment - 2014-03-12 04:01

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.

Kohsuke Kawaguchi added a comment - 2014-03-12 04:01 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.

aristedes added a comment - 2014-03-12 04:13

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?

aristedes added a comment - 2014-03-12 04:13 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?

Mike Konikoff added a comment - 2014-03-12 14:30 - 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.

Mike Konikoff added a comment - 2014-03-12 14:30 - 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.

Pedro Almeida added a comment - 2014-03-13 10:59

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

Pedro Almeida added a comment - 2014-03-13 10:59 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

Utopic Men added a comment - 2014-03-26 14:39

+1

Utopic Men added a comment - 2014-03-26 14:39 +1

Sergey Saraev added a comment - 2014-03-27 09:36

Hello Kohsuke.

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

Sergey Saraev added a comment - 2014-03-27 09:36 Hello Kohsuke. I can confirm problem for version 2.3-SNAPSHOT reported by Pedro. Maybe there are newer versions available to test?

Rob Collins added a comment - 2014-04-03 22:27

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.

Rob Collins added a comment - 2014-04-03 22:27 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.

Heiko Tappe added a comment - 2014-04-07 10:57

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

Heiko Tappe added a comment - 2014-04-07 10:57 Same here - can't see 1.8 option in Subversion Workspace Version with 2.3-SNAPSHOT

Charles Longuemart added a comment - 2014-04-30 13:32

+1

Charles Longuemart added a comment - 2014-04-30 13:32 +1

Tim Bradt added a comment - 2014-05-06 15:57

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

Tim Bradt added a comment - 2014-05-06 15:57 @Kohsuke...Any updates on fixes to the issues people are experiencing with the 2.3-SNAPSHOT?

Aneesh Vijendran added a comment - 2014-05-09 13:45

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

Aneesh Vijendran added a comment - 2014-05-09 13:45 I can confirm that there is this issue. Can we help to get this fixed in some ways? Like Coding or something like that?

mark 3000 added a comment - 2014-05-12 15:52

+1

mark 3000 added a comment - 2014-05-12 15:52 +1

Andreas Sieferlinger added a comment - 2014-05-22 12:15

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

Andreas Sieferlinger added a comment - 2014-05-22 12:15 The issue still seems to be there in version 2.4 which was released on May 16th.

michael oullion added a comment - 2014-06-03 06:36

+1

michael oullion added a comment - 2014-06-03 06:36 +1

Yuke Priyantoko added a comment - 2014-06-04 16:59

+1
need it,

Yuke Priyantoko added a comment - 2014-06-04 16:59 +1 need it,

Ignacio Sánchez added a comment - 2014-06-05 17:42

+1, please!

Ignacio Sánchez added a comment - 2014-06-05 17:42 +1, please!

Ireneusz Makowski added a comment - 2014-06-07 15:14

When this will be implemented?

Ireneusz Makowski added a comment - 2014-06-07 15:14 When this will be implemented?

Steve Carter added a comment - 2014-06-16 16:23

+1

Steve Carter added a comment - 2014-06-16 16:23 +1

aristedes added a comment - 2014-06-24 09:39

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

aristedes added a comment - 2014-06-24 09:39 @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.

Wouter de Vries added a comment - 2014-06-26 12:53

+1

Wouter de Vries added a comment - 2014-06-26 12:53 +1

Guymestef added a comment - 2014-06-26 16:32

+1

Guymestef added a comment - 2014-06-26 16:32 +1

Michael K added a comment - 2014-06-27 10:33

+1 need it too

Michael K added a comment - 2014-06-27 10:33 +1 need it too

Kanstantsin Shautsou added a comment - 2014-06-30 15:57

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

Kanstantsin Shautsou added a comment - 2014-06-30 15:57 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.

aristedes added a comment - 2014-07-01 01:52

@Kanstantsin

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

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

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

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

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

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

aristedes added a comment - 2014-07-01 01:52 @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?

Steve Wills added a comment - 2014-07-01 02:03

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

Steve Wills added a comment - 2014-07-01 02:03 @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?

Steve Wills added a comment - 2014-07-01 02:53

@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

Steve Wills added a comment - 2014-07-01 02:53 @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

aristedes added a comment - 2014-07-01 02:54

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.

aristedes added a comment - 2014-07-01 02:54 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.

aristedes added a comment - 2014-07-01 03:06

@steve

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

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

aristedes added a comment - 2014-07-01 03:06 @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.

Steve Wills added a comment - 2014-07-01 03:23

@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

Steve Wills added a comment - 2014-07-01 03:23 @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

Steve Wills added a comment - 2014-07-01 03:25

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

Steve Wills added a comment - 2014-07-01 03:25 @aristedes Well, I guess things could have been sent upstream via their bug tracker, see http://issues.tmatesoft.com/issues/SVNKIT

Steve Wills added a comment - 2014-07-01 03:32

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

Steve Wills added a comment - 2014-07-01 03:32 @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.

aristedes added a comment - 2014-07-01 04:24

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

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

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

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

aristedes added a comment - 2014-07-01 04:24 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?

Steve Wills added a comment - 2014-07-01 04:44 - 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?

Steve Wills added a comment - 2014-07-01 04:44 - 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?

aristedes added a comment - 2014-07-01 06:07

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?

aristedes added a comment - 2014-07-01 06:07 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?

Josef Andersson added a comment - 2014-07-18 20:04 - 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.

Josef Andersson added a comment - 2014-07-18 20:04 - 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.

Wing Lai added a comment - 2014-07-21 09:17 - 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

Wing Lai added a comment - 2014-07-21 09:17 - 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

David Aldrich added a comment - 2014-07-21 09:22

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

David Aldrich added a comment - 2014-07-21 09:22 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

Wing Lai added a comment - 2014-07-21 10:04

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

Wing Lai added a comment - 2014-07-21 10:04 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

aristedes added a comment - 2014-07-21 10:54

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.

aristedes added a comment - 2014-07-21 10:54 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.

Jeff Dege added a comment - 2014-07-24 16:27

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.

Jeff Dege added a comment - 2014-07-24 16:27 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.

Kelvin Fielding added a comment - 2014-07-24 16:59

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.

Kelvin Fielding added a comment - 2014-07-24 16:59 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.

Josh Kelley added a comment - 2014-07-24 19:58

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

Josh Kelley added a comment - 2014-07-24 19:58 @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.

Jeff Dege added a comment - 2014-07-24 20:14

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

Jeff Dege added a comment - 2014-07-24 20:14 I just installed the SVN 1.7.14 command-line tools on the build machine.

Tim Bradt added a comment - 2014-07-25 11:19

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.

Tim Bradt added a comment - 2014-07-25 11:19 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.

Saad Rahim added a comment - 2014-07-29 20:51

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.

Saad Rahim added a comment - 2014-07-29 20:51 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.

Jeff Dege added a comment - 2014-07-29 20:56

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?

Jeff Dege added a comment - 2014-07-29 20:56 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?

Saad Rahim added a comment - 2014-07-29 21:22

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.

Saad Rahim added a comment - 2014-07-29 21:22 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.

mark 3000 added a comment - 2014-07-29 21:40

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

mark 3000 added a comment - 2014-07-29 21:40 If someone would commit to fixing it for a set price, that could possibly make it easier to sell to management.

Quentin Hartman added a comment - 2014-07-29 21:46

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

Quentin Hartman added a comment - 2014-07-29 21:46 @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.

Ben Daniels added a comment - 2014-08-14 18:45

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

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

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

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

Ben Daniels added a comment - 2014-08-14 18:45 @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?

aristedes added a comment - 2014-08-17 08:13

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

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

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

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

aristedes added a comment - 2014-08-17 08:13 @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

Jenkins

Details

Description

Attachments

Attachments

Issue Links

Activity

Collapse comment: mark 3000 added a comment - 2013-09-24 19:10

Expand comment: mark 3000 added a comment - 2013-09-24 19:10

Collapse comment: Yishay Lehman added a comment - 2013-10-01 09:32

Expand comment: Yishay Lehman added a comment - 2013-10-01 09:32

Collapse comment: Peter Thorson added a comment - 2013-10-03 23:59

Expand comment: Peter Thorson added a comment - 2013-10-03 23:59

Collapse comment: Igor Koyfman added a comment - 2013-10-26 23:48

Expand comment: Igor Koyfman added a comment - 2013-10-26 23:48

Collapse comment: Brian Spratke added a comment - 2013-10-30 18:27

Expand comment: Brian Spratke added a comment - 2013-10-30 18:27

Collapse comment: Tim Bradt added a comment - 2013-10-30 19:17

Expand comment: Tim Bradt added a comment - 2013-10-30 19:17

Collapse comment: Tim Bradt added a comment - 2013-10-31 01:50

Expand comment: Tim Bradt added a comment - 2013-10-31 01:50

Collapse comment: François Dumont added a comment - 2013-11-04 18:29, Edited by François Dumont - 2013-11-04 18:30

Expand comment: François Dumont added a comment - 2013-11-04 18:29, Edited by François Dumont - 2013-11-04 18:30

Collapse comment: Christoph Moser added a comment - 2013-11-05 14:43

Expand comment: Christoph Moser added a comment - 2013-11-05 14:43

Collapse comment: Damien Finck added a comment - 2013-11-05 15:02

Expand comment: Damien Finck added a comment - 2013-11-05 15:02

Collapse comment: Jason Spotswood added a comment - 2013-11-06 11:54

Expand comment: Jason Spotswood added a comment - 2013-11-06 11:54

Collapse comment: John Salvo added a comment - 2013-11-07 00:15

Expand comment: John Salvo added a comment - 2013-11-07 00:15

Collapse comment: Jason Spotswood added a comment - 2013-11-07 01:25

Expand comment: Jason Spotswood added a comment - 2013-11-07 01:25

Collapse comment: Tim Bradt added a comment - 2013-11-07 12:57

Expand comment: Tim Bradt added a comment - 2013-11-07 12:57

Collapse comment: François Dumont added a comment - 2013-11-07 13:28

Expand comment: François Dumont added a comment - 2013-11-07 13:28

Collapse comment: John Salvo added a comment - 2013-11-07 22:51

Expand comment: John Salvo added a comment - 2013-11-07 22:51

Collapse comment: Tim Bradt added a comment - 2013-11-08 02:24

Expand comment: Tim Bradt added a comment - 2013-11-08 02:24

Collapse comment: centic added a comment - 2013-11-25 20:21

Expand comment: centic added a comment - 2013-11-25 20:21

Collapse comment: aristedes added a comment - 2013-11-29 06:50

Expand comment: aristedes added a comment - 2013-11-29 06:50

Collapse comment: François Dumont added a comment - 2013-11-29 07:40

Expand comment: François Dumont added a comment - 2013-11-29 07:40

Collapse comment: aristedes added a comment - 2013-12-02 06:13

Expand comment: aristedes added a comment - 2013-12-02 06:13

Collapse comment: David Pérez added a comment - 2013-12-03 10:39

Expand comment: David Pérez added a comment - 2013-12-03 10:39

Collapse comment: Lukáš Vasek added a comment - 2013-12-03 10:42

Expand comment: Lukáš Vasek added a comment - 2013-12-03 10:42

Collapse comment: John Knottenbelt added a comment - 2013-12-06 11:38

Expand comment: John Knottenbelt added a comment - 2013-12-06 11:38

Collapse comment: Arseniy Arseniy added a comment - 2013-12-16 09:36

Expand comment: Arseniy Arseniy added a comment - 2013-12-16 09:36

Collapse comment: Dimitar Sakarov added a comment - 2014-01-09 13:50

Expand comment: Dimitar Sakarov added a comment - 2014-01-09 13:50

Collapse comment: Jeebitesh Kalantri added a comment - 2014-01-13 10:31

Expand comment: Jeebitesh Kalantri added a comment - 2014-01-13 10:31

Collapse comment: Jens Hirschfeld added a comment - 2014-01-13 10:35

Expand comment: Jens Hirschfeld added a comment - 2014-01-13 10:35

Collapse comment: Karl Theil added a comment - 2014-01-17 15:30

Expand comment: Karl Theil added a comment - 2014-01-17 15:30

Collapse comment: Sergey Saraev added a comment - 2014-01-31 12:35

Expand comment: Sergey Saraev added a comment - 2014-01-31 12:35

Collapse comment: Hendrik Stehr added a comment - 2014-01-31 15:18

Expand comment: Hendrik Stehr added a comment - 2014-01-31 15:18

Collapse comment: Peter Schmitz added a comment - 2014-01-31 15:21

Expand comment: Peter Schmitz added a comment - 2014-01-31 15:21

Collapse comment: François Dumont added a comment - 2014-01-31 15:57

Expand comment: François Dumont added a comment - 2014-01-31 15:57

Collapse comment: Egor Sukhanov added a comment - 2014-01-31 16:07

Expand comment: Egor Sukhanov added a comment - 2014-01-31 16:07

Collapse comment: Jeff Behnke added a comment - 2014-01-31 16:24

Expand comment: Jeff Behnke added a comment - 2014-01-31 16:24

Collapse comment: Gregor K added a comment - 2014-01-31 17:36

Expand comment: Gregor K added a comment - 2014-01-31 17:36