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

Subversion Plugin does not support Subversion 1.7

    Details

    • Type: Improvement
    • Status: Resolved
    • Priority: Blocker
    • Resolution: Fixed
    • Component/s: subversion-plugin
    • Labels:
      None
    • Similar Issues:
      Show 5 results

      Attachments

      1. subversion.hpi
        4.12 MB
      2. subversion.hpi
        4.12 MB
      3. subversion.hpi
        4.12 MB

        Issue Links

          Activity

          Hide
          beau Gavin Baumanis added a comment -

          Hi Everyone,
          I have (unfortunately) no java skills to assist with a solution.
          But please let me add my +1 to the requirement to support SVN 1.7
          We have recently upgraded SVN to 1.7
          (It solves a few major issues we had with 1.6)

          And subsequently cannot use Jenkins for checking out / updating our code.
          We are able to do this via ANT, but it is slightly painful.

          Gavin.

          Show
          beau Gavin Baumanis added a comment - Hi Everyone, I have (unfortunately) no java skills to assist with a solution. But please let me add my +1 to the requirement to support SVN 1.7 We have recently upgraded SVN to 1.7 (It solves a few major issues we had with 1.6) And subsequently cannot use Jenkins for checking out / updating our code. We are able to do this via ANT, but it is slightly painful. Gavin.
          Hide
          jmanko John Manko added a comment -

          This is a critical bug. I just updated my subversion installation, and it broke Jenkins. I can't downgrade svn at this time.

          Show
          jmanko John Manko added a comment - This is a critical bug. I just updated my subversion installation, and it broke Jenkins. I can't downgrade svn at this time.
          Hide
          kutzi kutzi added a comment -

          Jenkins uses SVNKit internally for subversion support. Until SVNKit doesn't support 1.7 - announced for end of November http://svnkit.com/download.php - I'm afraid there isn't much we can do about it.

          Show
          kutzi kutzi added a comment - Jenkins uses SVNKit internally for subversion support. Until SVNKit doesn't support 1.7 - announced for end of November http://svnkit.com/download.php - I'm afraid there isn't much we can do about it.
          Hide
          zacharysyoung Zachary Young added a comment - - edited

          Thank you for the update kutzi.

          Show
          zacharysyoung Zachary Young added a comment - - edited Thank you for the update kutzi .
          Hide
          mikij Milutin Jovanovic added a comment -

          Does anyone know a workaround, even temporary/unstable one? I tried finding the unstable svnkit jars, but could not find them. Before I spend the time figuring out how to build it, I am curious, would simply replacing the Jenkins svnkit jars be a possible workaround?

          Is there a possibility of using JavaHL with Jenkins svn plugin?

          P.S. Thanks for your hard work. This is my first Jenkins issue in two years of usage.

          Show
          mikij Milutin Jovanovic added a comment - Does anyone know a workaround, even temporary/unstable one? I tried finding the unstable svnkit jars, but could not find them. Before I spend the time figuring out how to build it, I am curious, would simply replacing the Jenkins svnkit jars be a possible workaround? Is there a possibility of using JavaHL with Jenkins svn plugin? P.S. Thanks for your hard work. This is my first Jenkins issue in two years of usage.
          Hide
          mikij Milutin Jovanovic added a comment -

          BTW, I attempted simple jar substitution with trunk of svnkit, and that did not work. Bunch of missing class def exception.

          Show
          mikij Milutin Jovanovic added a comment - BTW, I attempted simple jar substitution with trunk of svnkit, and that did not work. Bunch of missing class def exception.
          Hide
          minger Matthew Inger added a comment -

          Why not allow usage of the command line client, instead of just SVNKit? At least this way, you're not always dependent on a particular downstream product?

          Show
          minger Matthew Inger added a comment - Why not allow usage of the command line client, instead of just SVNKit? At least this way, you're not always dependent on a particular downstream product?
          Hide
          dougborg Doug Borg added a comment - - edited

          Implementing something like what tjuerge suggests in JENKINS-2296 (using svnClientAdapter) for the SVN plugin would get you 1.7 support using the command-line option. This is probably not a trivial fix though.

          http://subclipse.tigris.org/source/browse/subclipse/trunk/svnClientAdapter/readme.txt?view=markup

          Show
          dougborg Doug Borg added a comment - - edited Implementing something like what tjuerge suggests in JENKINS-2296 (using svnClientAdapter) for the SVN plugin would get you 1.7 support using the command-line option. This is probably not a trivial fix though. http://subclipse.tigris.org/source/browse/subclipse/trunk/svnClientAdapter/readme.txt?view=markup
          Hide
          kaitsu Kai Virkki added a comment -

          Jenkins works fine with Subversion 1.7 if you use the HTTP protocol. The SVN protocol is broken due to a bug in SVNKIT: http://issues.tmatesoft.com/issue/SVNKIT-153

          Show
          kaitsu Kai Virkki added a comment - Jenkins works fine with Subversion 1.7 if you use the HTTP protocol. The SVN protocol is broken due to a bug in SVNKIT: http://issues.tmatesoft.com/issue/SVNKIT-153
          Hide
          dccarson David Carson added a comment -

          Note that SVNKit support for subversion 1.7 has two flavors. First, there is support for the 1.7 working copy format. This is not necessary to allow Jenkins to work with an svn 1.7 server.

          The other problem is a bug with how SVNKit forms the URL when checking out code from an svn 1.7 server. THIS bug must be fixed before Jenkins can incorporate it.

          I am happy to say that I checked SVNKit's site this morning, as I am as anxious as the rest of you. They have released 1.3.7, which claims to have fixed the URL bug. Now it is a matter of waiting until Jenkins has updated to the new SVNKit.

          Here is the text from the SVNKit site:

          Latest Stable Version
          6 Dec 2011, 19:02, version 1.3.7
          Changelog:
          + 1.7 Subversion servers compatibility issues fixed.
          + Export operation failed on missing directories, fixed.

          • For new 1.7 Subversion working copy format support
            please use SVNKit 1.7.0-alpha version.
          Show
          dccarson David Carson added a comment - Note that SVNKit support for subversion 1.7 has two flavors. First, there is support for the 1.7 working copy format. This is not necessary to allow Jenkins to work with an svn 1.7 server. The other problem is a bug with how SVNKit forms the URL when checking out code from an svn 1.7 server. THIS bug must be fixed before Jenkins can incorporate it. I am happy to say that I checked SVNKit's site this morning, as I am as anxious as the rest of you. They have released 1.3.7, which claims to have fixed the URL bug. Now it is a matter of waiting until Jenkins has updated to the new SVNKit. Here is the text from the SVNKit site: Latest Stable Version 6 Dec 2011, 19:02, version 1.3.7 Changelog: + 1.7 Subversion servers compatibility issues fixed. + Export operation failed on missing directories, fixed. For new 1.7 Subversion working copy format support please use SVNKit 1.7.0-alpha version.
          Hide
          alexanderv Alexander Veit added a comment -

          We are experiencing the same problem after an update to Subversion 1.7. Jenkins with over 120 projects all stands still for two weeks now.

          Unfortunately switching to another protocol is not an option for us.

          Show
          alexanderv Alexander Veit added a comment - We are experiencing the same problem after an update to Subversion 1.7. Jenkins with over 120 projects all stands still for two weeks now. Unfortunately switching to another protocol is not an option for us.
          Hide
          mulrich Matthias Ulrich added a comment -

          We are delaying the update of our SVN Server due to this Issue and for several other reasons we really would like to update...

          Show
          mulrich Matthias Ulrich added a comment - We are delaying the update of our SVN Server due to this Issue and for several other reasons we really would like to update...
          Hide
          jms_nh Jason Sachs added a comment -

          >Why not allow usage of the command line client, instead of just SVNKit? At least this way, you're not always dependent on a particular downstream product?

          I second this....

          Show
          jms_nh Jason Sachs added a comment - >Why not allow usage of the command line client, instead of just SVNKit? At least this way, you're not always dependent on a particular downstream product? I second this....
          Hide
          rolandzwaga Roland Zwaga added a comment -

          Is there some sort of ETA for this fix? I have quite a few projects that can no longer be built by Jenkins. I understand OS work is mostly done in people's spare time, but a rough estimate of when this can be fixed would be really appreciated.
          Thanks a lot in advance.

          Show
          rolandzwaga Roland Zwaga added a comment - Is there some sort of ETA for this fix? I have quite a few projects that can no longer be built by Jenkins. I understand OS work is mostly done in people's spare time, but a rough estimate of when this can be fixed would be really appreciated. Thanks a lot in advance.
          Hide
          nurikabe Evan Owens added a comment -

          >Why not allow usage of the command line client, instead of just SVNKit? At least this way, you're not always dependent on a particular downstream product?

          I third this.

          Show
          nurikabe Evan Owens added a comment - >Why not allow usage of the command line client, instead of just SVNKit? At least this way, you're not always dependent on a particular downstream product? I third this.
          Hide
          kutzi kutzi added a comment -

          >Why not allow usage of the command line client, instead of just SVNKit? At least this way, you're not always dependent on a particular downstream product?

          In that case you're dependent on having the user installed the 'right' version of the native svn client. I'm not sure if that is the better alternative.

          Show
          kutzi kutzi added a comment - >Why not allow usage of the command line client, instead of just SVNKit? At least this way, you're not always dependent on a particular downstream product? In that case you're dependent on having the user installed the 'right' version of the native svn client. I'm not sure if that is the better alternative.
          Hide
          mikij Milutin Jovanovic added a comment -

          > Is there some sort of ETA for this fix?

          Jenkins SVN depends on SVNKIT. They have been promising a new version for a while, but always ran into trouble. Currently their web site says release Feb 2012, but since they are about to release beta, I am guessing March. It's a guess. I am sure Jenkins SVN people will update the plugin as soon as the underlying library is updated.

          > In that case you're dependent on having the user installed the 'right' version of the native svn client. I'm not sure if that is the better alternative.

          It worked fine for Netbeans for months... Jumping through some hoops is prefereable to it not working at all. I fourth this.

          Show
          mikij Milutin Jovanovic added a comment - > Is there some sort of ETA for this fix? Jenkins SVN depends on SVNKIT. They have been promising a new version for a while, but always ran into trouble. Currently their web site says release Feb 2012, but since they are about to release beta, I am guessing March. It's a guess. I am sure Jenkins SVN people will update the plugin as soon as the underlying library is updated. > In that case you're dependent on having the user installed the 'right' version of the native svn client. I'm not sure if that is the better alternative. It worked fine for Netbeans for months... Jumping through some hoops is prefereable to it not working at all. I fourth this.
          Hide
          gnustavo Gustavo Chaves added a comment -

          > In that case you're dependent on having the user installed the 'right' version of the native svn client. I'm not sure if that is the better alternative.

          What about a global or a job configuration option to let the user decide which svn client to use?

          Show
          gnustavo Gustavo Chaves added a comment - > In that case you're dependent on having the user installed the 'right' version of the native svn client. I'm not sure if that is the better alternative. What about a global or a job configuration option to let the user decide which svn client to use?
          Hide
          displaced Chris Platts added a comment -

          Hi,

          I've got a few projects which perform a svn commit as part of their build process (a script updates version numbers to match the build/revision before committing those changes back to the repository).

          As a workaround, I've added an 'svn upgrade .' command before the 'svn commit .' statement. This means that the old-format working dir created by Jenkins is able to be committed at the end of the build.

          This works, but almost doubles the time that each build takes. I'm really looking forward to an update to this plugin to support v1.7 working copies.

          Of course, as mentioned, I'd also have no problem with an option to use the native svn client.

          Thanks,
          Chris

          Show
          displaced Chris Platts added a comment - Hi, I've got a few projects which perform a svn commit as part of their build process (a script updates version numbers to match the build/revision before committing those changes back to the repository). As a workaround, I've added an 'svn upgrade .' command before the 'svn commit .' statement. This means that the old-format working dir created by Jenkins is able to be committed at the end of the build. This works, but almost doubles the time that each build takes. I'm really looking forward to an update to this plugin to support v1.7 working copies. Of course, as mentioned, I'd also have no problem with an option to use the native svn client. Thanks, Chris
          Hide
          gsxjay Jay Beeckman added a comment -

          Any update on this? It appears that SVNKIT has updated their stuff? An ETA would be great.

          Show
          gsxjay Jay Beeckman added a comment - Any update on this? It appears that SVNKIT has updated their stuff? An ETA would be great.
          Hide
          mikij Milutin Jovanovic added a comment -

          I am not the maintainer, but interested in this...

          SVNKit is still in release candidate stage, so I don't think svn plugin will be updated until SVNKit is fully released.

          Show
          mikij Milutin Jovanovic added a comment - I am not the maintainer, but interested in this... SVNKit is still in release candidate stage, so I don't think svn plugin will be updated until SVNKit is fully released.
          Hide
          gsxjay Jay Beeckman added a comment -

          This is according to SVNKit's web page (http://svnkit.com/download.php):

          "Lastest stable version of SVNKit (1.3.7) is not compatible with Subversion 1.7 working copy format. However, SVNKit 1.7 is under development now and we plan to release it in 12th of April 2012. We plan to publish first Release Candidate build till the end of February 2012."

          This is in three days, when could we reasonably expect this to be rolled into the plugin if they do indeed release on the 12th?

          Show
          gsxjay Jay Beeckman added a comment - This is according to SVNKit's web page ( http://svnkit.com/download.php): "Lastest stable version of SVNKit (1.3.7) is not compatible with Subversion 1.7 working copy format. However, SVNKit 1.7 is under development now and we plan to release it in 12th of April 2012. We plan to publish first Release Candidate build till the end of February 2012." This is in three days, when could we reasonably expect this to be rolled into the plugin if they do indeed release on the 12th?
          Hide
          gnustavo Gustavo Chaves added a comment -

          SVNKit 1.7.4 has just been released. The download page says this:

          Lastest stable version of SVNKit (1.7.4) is compatible with Subversion 1.7 working copy format and with Subversion 1.7 servers.

          Show
          gnustavo Gustavo Chaves added a comment - SVNKit 1.7.4 has just been released. The download page says this: Lastest stable version of SVNKit ( 1.7.4 ) is compatible with Subversion 1.7 working copy format and with Subversion 1.7 servers.
          Hide
          hizhik Dmitry Teterevyatnikov added a comment -

          Due to released SVNKit, do you have any plans to update Subversion plugin?

          Show
          hizhik Dmitry Teterevyatnikov added a comment - Due to released SVNKit, do you have any plans to update Subversion plugin?
          Hide
          jtrueloveks Jeremy Truelove added a comment -

          Any updates on this? It appears there is a stable release of SVNKit which supports 1.7

          Show
          jtrueloveks Jeremy Truelove added a comment - Any updates on this? It appears there is a stable release of SVNKit which supports 1.7
          Hide
          softhinker Qin Ding added a comment - - edited

          There is my workaround :
          1. Install the latest CollabNet Subversion Client to the server, which provides svn command-line tool.
          2. Put all maven commands into a shell, i.e. bat for Windows.
          3. Use maven-antrun-plugin to execute that shell.
          4. In Jenkins configuration page, just use 'antrun:run' as the 'Goals and options'.

          It works because the shell will use the system variable where PATH includes the latest CollabNet path rather than the old svn path used by Jenkins.

          My website describes more : http://www.softhinker.com/in-the-news/howtomakejenkinssupportsubversion17

          Show
          softhinker Qin Ding added a comment - - edited There is my workaround : 1. Install the latest CollabNet Subversion Client to the server, which provides svn command-line tool. 2. Put all maven commands into a shell, i.e. bat for Windows. 3. Use maven-antrun-plugin to execute that shell. 4. In Jenkins configuration page, just use 'antrun:run' as the 'Goals and options'. It works because the shell will use the system variable where PATH includes the latest CollabNet path rather than the old svn path used by Jenkins. My website describes more : http://www.softhinker.com/in-the-news/howtomakejenkinssupportsubversion17
          Hide
          hizhik Dmitry Teterevyatnikov added a comment -

          Your workaround seems good, but how you can replace Jenkins CI SVN checkout/update from SVN action? Current problem with SVN 1.7 support in Jenkins is: Jenkins will check-out/update project code from SVN 1.7 server in outdated SVN 1.6 file format and latest command-line SVN clients are not compatible with old SVN 1.6 file format

          Show
          hizhik Dmitry Teterevyatnikov added a comment - Your workaround seems good, but how you can replace Jenkins CI SVN checkout/update from SVN action? Current problem with SVN 1.7 support in Jenkins is: Jenkins will check-out/update project code from SVN 1.7 server in outdated SVN 1.6 file format and latest command-line SVN clients are not compatible with old SVN 1.6 file format
          Hide
          jtrueloveks Jeremy Truelove added a comment -

          Not everyone uses ant/maven

          Show
          jtrueloveks Jeremy Truelove added a comment - Not everyone uses ant/maven
          Hide
          hizhik Dmitry Teterevyatnikov added a comment -

          I am agree with Jeremy, i.e. everyone wants to use the Jenkins with all its features "from the box" with the best performance. Does anyone knows how to speedUp this issue to be resolved?

          Show
          hizhik Dmitry Teterevyatnikov added a comment - I am agree with Jeremy, i.e. everyone wants to use the Jenkins with all its features "from the box" with the best performance. Does anyone knows how to speedUp this issue to be resolved?
          Hide
          mulrich Matthias Ulrich added a comment - - edited

          I also want to point out, that the workaround is not applicable to all use cases of Jenkins and that this is a show stopper in some situations.
          So as svnkit for svn 1.7 is availble now, this issue should be assigned as it is a "Blocker".

          Show
          mulrich Matthias Ulrich added a comment - - edited I also want to point out, that the workaround is not applicable to all use cases of Jenkins and that this is a show stopper in some situations. So as svnkit for svn 1.7 is availble now, this issue should be assigned as it is a "Blocker".
          Hide
          jk Jan Klass added a comment -

          @Dmitry:
          The only thing you can do to speed up the process is

          • vote on this issue (left of top right)
          • fix / implement it yourself and commit / provide patch/diff
          Show
          jk Jan Klass added a comment - @Dmitry: The only thing you can do to speed up the process is vote on this issue (left of top right) fix / implement it yourself and commit / provide patch/diff
          Hide
          gsxjay Jay Beeckman added a comment -

          Jan, I have considered trying to get the fix in myself. If I wasn't so busy right now I would. This is holding up a big integration we have done with our delivery process, so it's killing me, but not something I could do right away. I do like your suggestion of voting, more voices the better

          Jay

          Show
          gsxjay Jay Beeckman added a comment - Jan, I have considered trying to get the fix in myself. If I wasn't so busy right now I would. This is holding up a big integration we have done with our delivery process, so it's killing me, but not something I could do right away. I do like your suggestion of voting, more voices the better Jay
          Hide
          jtrueloveks Jeremy Truelove added a comment -

          Are there any plans going forward to decouple Jenkins from specific svn versions, i.e. allow the user to specify the executable? Like what is done for git etc...

          Show
          jtrueloveks Jeremy Truelove added a comment - Are there any plans going forward to decouple Jenkins from specific svn versions, i.e. allow the user to specify the executable? Like what is done for git etc...
          Hide
          shryke Jamie Press added a comment -

          SVNKit 1.7.4 is now out, which does allow functionality with both 1.7 server and working copies...

          /hopeful glance?

          Show
          shryke Jamie Press added a comment - SVNKit 1.7.4 is now out, which does allow functionality with both 1.7 server and working copies... /hopeful glance?
          Hide
          hizhik Dmitry Teterevyatnikov added a comment -

          Looks like Jenkins Jira is "dead"... really strange for a so popular service/product. Does anyone knows how to force this issue to be resolved (together with voiting)?

          Show
          hizhik Dmitry Teterevyatnikov added a comment - Looks like Jenkins Jira is "dead"... really strange for a so popular service/product. Does anyone knows how to force this issue to be resolved (together with voiting)?
          Hide
          dreyguy Dreyguy added a comment -

          The hudson team did some work on this that included removing the customization to svn kit. If the same can be done with jenkins, you could just use the new svnkit library.

          See http://issues.hudson-ci.org/browse/HUDSON-9111 for more info.

          Show
          dreyguy Dreyguy added a comment - The hudson team did some work on this that included removing the customization to svn kit. If the same can be done with jenkins, you could just use the new svnkit library. See http://issues.hudson-ci.org/browse/HUDSON-9111 for more info.
          Hide
          shryke Jamie Press added a comment -

          In JENKINS-11933, the 'duplicate' issue for this, someone added a patch file that theoretically upgrades the svnkit version from the defective 1.3.6.1 to the partially working 1.3.7 (this version can apparently speak to the 1.7.x server, though not 1.7.x working copy).

          As I would guess that most of us are only using Jenkins to check out the latest version, this may serve as a workaround for many. However, applying a patch file is a little beyond my expertise. Is anyone able to see if that patch works, and if so, post the patched svnkit? It apparently makes a version called 1.3.7-jenkins-0.

          All that being said, Dreyguy is right in saying the Hudson team made the right move. Decoupling the svnkit from the plugin would be desirable.

          Show
          shryke Jamie Press added a comment - In JENKINS-11933 , the 'duplicate' issue for this, someone added a patch file that theoretically upgrades the svnkit version from the defective 1.3.6.1 to the partially working 1.3.7 (this version can apparently speak to the 1.7.x server, though not 1.7.x working copy). As I would guess that most of us are only using Jenkins to check out the latest version, this may serve as a workaround for many. However, applying a patch file is a little beyond my expertise. Is anyone able to see if that patch works, and if so, post the patched svnkit? It apparently makes a version called 1.3.7-jenkins-0. All that being said, Dreyguy is right in saying the Hudson team made the right move. Decoupling the svnkit from the plugin would be desirable.
          Hide
          centic centic added a comment -

          I have now attached the .hpi file that I use locally for getting at least 1.7-server supported in Jenkins to JENKINS-11933.

          Show
          centic centic added a comment - I have now attached the .hpi file that I use locally for getting at least 1.7-server supported in Jenkins to JENKINS-11933 .
          Hide
          nezah hyunsoo lee added a comment -

          Thanks a lot!!! centic!!
          It's working

          Show
          nezah hyunsoo lee added a comment - Thanks a lot!!! centic!! It's working
          Hide
          hizhik Dmitry Teterevyatnikov added a comment -

          @centric: Thanks for the patch. But it looks like even with your patch we still have a problem with full SVN 1.7 support by Jenkins.

          I.e. currently on our build environments, Jenkins works fine with SVN 1.7 with old 1.6 SVN format. Everithing works correct, but.. performance of all SVN related operations is horrible. I.e. checkout of SVN 1.7 trunk by Jenkins with size about 100 MB takes about 30-40 minutes. Due to SVN 1.6 working format is used by current version of Jenkins SVN plugin, newest command-line SVN clients works with old SVN 1.6 format really slow. At the result our releases takes more then hour, where 40 minutes - it is a SVN-related tasks.
          I am totally sure that update of Subversion plugin on Jenkins to latest SVNKit will fix all SVN performance re;lated problems.

          Show
          hizhik Dmitry Teterevyatnikov added a comment - @centric: Thanks for the patch. But it looks like even with your patch we still have a problem with full SVN 1.7 support by Jenkins. I.e. currently on our build environments, Jenkins works fine with SVN 1.7 with old 1.6 SVN format. Everithing works correct, but.. performance of all SVN related operations is horrible. I.e. checkout of SVN 1.7 trunk by Jenkins with size about 100 MB takes about 30-40 minutes. Due to SVN 1.6 working format is used by current version of Jenkins SVN plugin, newest command-line SVN clients works with old SVN 1.6 format really slow. At the result our releases takes more then hour, where 40 minutes - it is a SVN-related tasks. I am totally sure that update of Subversion plugin on Jenkins to latest SVNKit will fix all SVN performance re;lated problems.
          Hide
          centic centic added a comment -

          Sorry, I already gave it a try and started the merge of 1.7.4 and the jenkins-specific changes, but there are a lot of conflicts and I lack some knowledge about the changes in the jenkins-version to tell me how to solve them... Maybe I try again and see if a hacky-wacky merge leads at least to a workable solution...

          Show
          centic centic added a comment - Sorry, I already gave it a try and started the merge of 1.7.4 and the jenkins-specific changes, but there are a lot of conflicts and I lack some knowledge about the changes in the jenkins-version to tell me how to solve them... Maybe I try again and see if a hacky-wacky merge leads at least to a workable solution...
          Hide
          kkartikeya Kumar Kartikeya added a comment -

          I tried replacing old current jars in /plugins/subversion/WEB-INF/lib/ with sequence-library-1.0.1.jar svnkit-1.7.4.jar, but getting following

          FATAL: org/tmatesoft/svn/core/auth/ISVNAuthenticationOutcomeListener
          java.lang.NoClassDefFoundError: org/tmatesoft/svn/core/auth/ISVNAuthenticationOutcomeListener

          Show
          kkartikeya Kumar Kartikeya added a comment - I tried replacing old current jars in /plugins/subversion/WEB-INF/lib/ with sequence-library-1.0.1.jar svnkit-1.7.4.jar, but getting following FATAL: org/tmatesoft/svn/core/auth/ISVNAuthenticationOutcomeListener java.lang.NoClassDefFoundError: org/tmatesoft/svn/core/auth/ISVNAuthenticationOutcomeListener
          Hide
          centic centic added a comment -

          Please hold on for just a bit longer, I managed to merge the necessary pieces and started local testing yesterday, so far it looks promising.

          I'll try to post an updated hack-build of the plugin and put all the necessary changes (svnkit/trilead-ssh2/subversion-plugin) on github so they can be reviewed and applied to the official sources easily. (I am not associated with any of these projects currently, so I cannot do offical builds here)

          Show
          centic centic added a comment - Please hold on for just a bit longer, I managed to merge the necessary pieces and started local testing yesterday, so far it looks promising. I'll try to post an updated hack-build of the plugin and put all the necessary changes (svnkit/trilead-ssh2/subversion-plugin) on github so they can be reviewed and applied to the official sources easily. (I am not associated with any of these projects currently, so I cannot do offical builds here)
          Hide
          centic centic added a comment -

          Please give the plugin available at JENKINS-11933 a try now, I did a minimal bit of local verification, so far it works for me.

          Show
          centic centic added a comment - Please give the plugin available at JENKINS-11933 a try now, I did a minimal bit of local verification, so far it works for me.
          Hide
          hizhik Dmitry Teterevyatnikov added a comment -

          Great job Centric! Thank you. I haven't tried your patches (because fo have no idea how to use them), but does anyone knows how this fix can be forced to be processed into the product?

          This Jira is the most voted blocker in this project, why it is not assigned to anyone who have rights to include fixes in the product?

          Show
          hizhik Dmitry Teterevyatnikov added a comment - Great job Centric! Thank you. I haven't tried your patches (because fo have no idea how to use them), but does anyone knows how this fix can be forced to be processed into the product? This Jira is the most voted blocker in this project, why it is not assigned to anyone who have rights to include fixes in the product?
          Hide
          heinzepreller0815 Robert Lachner added a comment -

          One Question:
          Do i really have to wait for a working 1.7.4 SVN Plugin for JIRA ? If i use Jenkins against 1.7.4 SVN with 1.6 Plugin everything works fine except that the checked out workspaces are in the old 1.6 svn format. Are there any problems that i don't see ?

          Show
          heinzepreller0815 Robert Lachner added a comment - One Question: Do i really have to wait for a working 1.7.4 SVN Plugin for JIRA ? If i use Jenkins against 1.7.4 SVN with 1.6 Plugin everything works fine except that the checked out workspaces are in the old 1.6 svn format. Are there any problems that i don't see ?
          Hide
          hizhik Dmitry Teterevyatnikov added a comment -

          @Robert: Yes, it will work but really slow. Project workspace update/checkout and checkout from tag by old command-line svn clients (to support SVN 1.6 file format) will take a LOT of time. By example, our 100MB trunk svn checkout takes 40 minutes. So, update of svn pluging with new SVN file format support will increase perforamce of SVN related operations in 10 times!

          Show
          hizhik Dmitry Teterevyatnikov added a comment - @Robert: Yes, it will work but really slow. Project workspace update/checkout and checkout from tag by old command-line svn clients (to support SVN 1.6 file format) will take a LOT of time. By example, our 100MB trunk svn checkout takes 40 minutes. So, update of svn pluging with new SVN file format support will increase perforamce of SVN related operations in 10 times!
          Hide
          heinzepreller0815 Robert Lachner added a comment - - edited

          @Dimitry
          ok, just tried 60MB checkout on a Virtual Machine with Jenkins 1.461, SVN Plugin 1.34 and VisualSVN 2.5.4(the Version with SVN 1.7.4), it takes about 30seconds.
          Nothing unusual so far...
          Maybe the older 1.34 Version does not have this long checkout behaviour ?
          ...just tried with updated Plugin to 1.39, same result

          Show
          heinzepreller0815 Robert Lachner added a comment - - edited @Dimitry ok, just tried 60MB checkout on a Virtual Machine with Jenkins 1.461, SVN Plugin 1.34 and VisualSVN 2.5.4(the Version with SVN 1.7.4), it takes about 30seconds. Nothing unusual so far... Maybe the older 1.34 Version does not have this long checkout behaviour ? ...just tried with updated Plugin to 1.39, same result
          Hide
          jbuchberger jbuchberger added a comment -

          FWIW, svnkit 1.7.4 hit maven central and should be generally available

          Show
          jbuchberger jbuchberger added a comment - FWIW, svnkit 1.7.4 hit maven central and should be generally available
          Hide
          ntumba ntumba lobo added a comment -

          Are we soon going to have a fix in the product for this issue ?
          I cannot do maven releases because of this....

          Show
          ntumba ntumba lobo added a comment - Are we soon going to have a fix in the product for this issue ? I cannot do maven releases because of this....
          Hide
          rvillanu Richard Villanueva added a comment -

          Hi,

          We also are waiting for this update for 2 months, it should be great because of the SVN migration is postponed until the compatibility between our Jenkins platform and our new SVN plaform is made;

          Good luke for the final lap of merging your work in the next release of Jenkins

          Regards
          Richard

          Show
          rvillanu Richard Villanueva added a comment - Hi, We also are waiting for this update for 2 months, it should be great because of the SVN migration is postponed until the compatibility between our Jenkins platform and our new SVN plaform is made; Good luke for the final lap of merging your work in the next release of Jenkins Regards Richard
          Hide
          kohsuke Kohsuke Kawaguchi added a comment - - edited

          Uploaded 1.40 RC that supports Subversion 1.7. I'm running this on http://ci.jenkins-ci.org/ now, but any additional beta testing appreciated.

          It does pass all the tests we have, but there are major changes in SVNKit, so I'm being bit cautious.

          Show
          kohsuke Kohsuke Kawaguchi added a comment - - edited Uploaded 1.40 RC that supports Subversion 1.7. I'm running this on http://ci.jenkins-ci.org/ now, but any additional beta testing appreciated. It does pass all the tests we have, but there are major changes in SVNKit, so I'm being bit cautious.
          Hide
          turch Alexei Turchanikov added a comment -

          I just tried the 1.40 RC, it throws an exception when attempting to check out to a directory that isn't a working copy (such as when "Always check out a fresh copy" is selected or if this is the first build):

          ERROR: Failed to check out https://domain/svn/repo
          org.tmatesoft.svn.core.SVNException: svn: E155007: 'C:\Data\Jenkins\workspace\job\src' is not a working copy
          at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
          at org.tmatesoft.svn.core.internal.wc.admin.SVNAdminAreaFactory.open(SVNAdminAreaFactory.java:170)
          at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.doOpen(SVNWCAccess.java:379)
          at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.open(SVNWCAccess.java:283)
          at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.open(SVNWCAccess.java:276)
          at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.openAnchor(SVNWCAccess.java:171)
          at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:514)
          at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doCheckout(SVNUpdateClient16.java:965)
          at org.tmatesoft.svn.core.internal.wc2.old.SvnOldCheckout.run(SvnOldCheckout.java:19)
          at org.tmatesoft.svn.core.internal.wc2.old.SvnOldCheckout.run(SvnOldCheckout.java:8)
          at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
          at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1221)
          at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:292)
          at org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:781)
          at hudson.scm.subversion.CheckoutUpdater$1.perform(CheckoutUpdater.java:86)
          at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:144)
          at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:789)
          at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:770)
          at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:753)
          at hudson.FilePath.act(FilePath.java:832)
          at hudson.FilePath.act(FilePath.java:814)
          at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:743)
          at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:685)
          at hudson.model.AbstractProject.checkout(AbstractProject.java:1218)
          at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:581)
          at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:470)
          at hudson.model.Run.run(Run.java:1434)
          at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
          at hudson.model.ResourceController.execute(ResourceController.java:88)
          at hudson.model.Executor.run(Executor.java:239)
          Caused by: svn: E155007: 'C:\Data\Jenkins\workspace\job\src' is not a working copy
          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.wc.admin.SVNAdminAreaFactory.open(SVNAdminAreaFactory.java:165)
          ... 28 more
          FATAL: null
          java.lang.NullPointerException
          at java.util.ArrayList.addAll(Unknown Source)
          at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:743)
          at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:685)
          at hudson.model.AbstractProject.checkout(AbstractProject.java:1218)
          at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:581)
          at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:470)
          at hudson.model.Run.run(Run.java:1434)
          at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
          at hudson.model.ResourceController.execute(ResourceController.java:88)
          at hudson.model.Executor.run(Executor.java:239)

          Show
          turch Alexei Turchanikov added a comment - I just tried the 1.40 RC, it throws an exception when attempting to check out to a directory that isn't a working copy (such as when "Always check out a fresh copy" is selected or if this is the first build): ERROR: Failed to check out https://domain/svn/repo org.tmatesoft.svn.core.SVNException: svn: E155007: 'C:\Data\Jenkins\workspace\job\src' is not a working copy at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.admin.SVNAdminAreaFactory.open(SVNAdminAreaFactory.java:170) at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.doOpen(SVNWCAccess.java:379) at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.open(SVNWCAccess.java:283) at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.open(SVNWCAccess.java:276) at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.openAnchor(SVNWCAccess.java:171) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:514) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doCheckout(SVNUpdateClient16.java:965) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldCheckout.run(SvnOldCheckout.java:19) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldCheckout.run(SvnOldCheckout.java:8) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1221) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:292) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:781) at hudson.scm.subversion.CheckoutUpdater$1.perform(CheckoutUpdater.java:86) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:144) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:789) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:770) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:753) at hudson.FilePath.act(FilePath.java:832) at hudson.FilePath.act(FilePath.java:814) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:743) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:685) at hudson.model.AbstractProject.checkout(AbstractProject.java:1218) at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:581) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:470) at hudson.model.Run.run(Run.java:1434) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:239) Caused by: svn: E155007: 'C:\Data\Jenkins\workspace\job\src' is not a working copy 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.wc.admin.SVNAdminAreaFactory.open(SVNAdminAreaFactory.java:165) ... 28 more FATAL: null java.lang.NullPointerException at java.util.ArrayList.addAll(Unknown Source) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:743) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:685) at hudson.model.AbstractProject.checkout(AbstractProject.java:1218) at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:581) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:470) at hudson.model.Run.run(Run.java:1434) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:239)
          Hide
          kohsuke Kohsuke Kawaguchi added a comment -

          Alexei, I couldn't reproduce the problem.

          When this error happens, do you have C:\Data\Jenkins\workspace\job\src\.svn? I step executed the code and it does create the workspace right before the code gets to here.

          The other experiment I'd like you to try is to use the scripting console, run "org.tmatesoft.svn.core.internal.wc.admin.SVNAdminAreaFactory.ourFactories;", and report back what you see. I wonder if someone else is setting that collection to empty, which would explain this.

          I continue to look for other people trying out this version.

          Show
          kohsuke Kohsuke Kawaguchi added a comment - Alexei, I couldn't reproduce the problem. When this error happens, do you have C:\Data\Jenkins\workspace\job\src\.svn? I step executed the code and it does create the workspace right before the code gets to here. The other experiment I'd like you to try is to use the scripting console, run "org.tmatesoft.svn.core.internal.wc.admin.SVNAdminAreaFactory.ourFactories;", and report back what you see. I wonder if someone else is setting that collection to empty, which would explain this. I continue to look for other people trying out this version.
          Hide
          salvojo John Salvo added a comment - - edited

          Out of curiosity, those experiencing long delays during any SVN operation when they upgraded their SVN plugin to use 1.7 format .. did you upgrade your working copy from 1.6 to 1.7 format first ?

          http://subversion.apache.org/docs/release-notes/1.7.html#wc-ng

          To quote:

          "Upgrading the Working Copy

          Subversion 1.7 introduces substantial changes to the working copy format. In previous releases of Subversion, Subversion would automatically update the working copy to the new format when a write operation was performed. Subversion 1.7, however, will make this a manual step. Before using Subversion 1.7 with their working copies, users will be required to run a new command, svn upgrade to update the metadata to the new format. This command may take a while, and for some users, it may be more practical to simply checkout a new working copy."

          Show
          salvojo John Salvo added a comment - - edited Out of curiosity, those experiencing long delays during any SVN operation when they upgraded their SVN plugin to use 1.7 format .. did you upgrade your working copy from 1.6 to 1.7 format first ? http://subversion.apache.org/docs/release-notes/1.7.html#wc-ng To quote: "Upgrading the Working Copy Subversion 1.7 introduces substantial changes to the working copy format. In previous releases of Subversion, Subversion would automatically update the working copy to the new format when a write operation was performed. Subversion 1.7, however, will make this a manual step. Before using Subversion 1.7 with their working copies, users will be required to run a new command, svn upgrade to update the metadata to the new format. This command may take a while, and for some users, it may be more practical to simply checkout a new working copy."
          Hide
          plillevold Peter Lillevold added a comment -

          The question is: will the new SVNKit do an automatic working copy upgrade? Or are we better of scrapping all our existing working copies?

          Show
          plillevold Peter Lillevold added a comment - The question is: will the new SVNKit do an automatic working copy upgrade? Or are we better of scrapping all our existing working copies?
          Hide
          jk Jan Klass added a comment -

          An automatic upgrade should definitely not be the way to go, as workspaces, tool- and build-chains may depend on the old working copy structure.
          Maybe a flag setting for enabling an automatic upgrade when the old format is identified would be an option.

          Show
          jk Jan Klass added a comment - An automatic upgrade should definitely not be the way to go, as workspaces, tool- and build-chains may depend on the old working copy structure. Maybe a flag setting for enabling an automatic upgrade when the old format is identified would be an option.
          Hide
          brenuart brenuart added a comment -

          Don't see any benefit of having such an "auto upgrade" feature...
          What's the problem in just dropping the workspaces and let Jenkins checkout the projects again ?
          It's just a one-time operation...

          Show
          brenuart brenuart added a comment - Don't see any benefit of having such an "auto upgrade" feature... What's the problem in just dropping the workspaces and let Jenkins checkout the projects again ? It's just a one-time operation...
          Hide
          danlewis Dan Lewis added a comment -

          agree. bonus points if we can fail fast with an appropriate error message explaining corrective procedure, e.g. "jenkins does not support auto-update of pre-SVN 1.7 workspaces to 1.7; please remove workspaces and restart build" or some such

          Show
          danlewis Dan Lewis added a comment - agree. bonus points if we can fail fast with an appropriate error message explaining corrective procedure, e.g. "jenkins does not support auto-update of pre-SVN 1.7 workspaces to 1.7; please remove workspaces and restart build" or some such
          Hide
          jk Jan Klass added a comment -

          I installed version 140RC locally.
          The parametrized build (List subversion tags and more) only lists trunk.
          See also the other ticket https://issues.jenkins-ci.org/browse/JENKINS-11933?focusedCommentId=162399#comment-162399

          On Configuration: The repository is being accepted as valid, root path as well as subpaths. Did not check out on it yet.

          Show
          jk Jan Klass added a comment - I installed version 140RC locally. The parametrized build (List subversion tags and more) only lists trunk. See also the other ticket https://issues.jenkins-ci.org/browse/JENKINS-11933?focusedCommentId=162399#comment-162399 On Configuration: The repository is being accepted as valid, root path as well as subpaths. Did not check out on it yet.
          Hide
          jk Jan Klass added a comment - - edited

          I just tried to check out a fresh copy, which did not succeed.

          The URI was a subpath of trunk, so not trunk itself.

          Checking out a fresh workspace because C:\jenkins\workspace\ProjName\MyFolder doesn't exist
          Cleaning local Directory MyFolder
          Checking out svn://srv/repopath/trunk/MyFolder
          ERROR: Failed to check out svn://srv/repopath/trunk/MyFolder
          org.tmatesoft.svn.core.SVNException: svn: E155007: 'C:\jenkins\workspace\ProjName\MyFolder ' is not a working copy

          Checking out to a 1.6 workspace instead of 1.7 worked with the same configuration.

          /e:
          Checking out trunk to a 1.7 workspace fails as well, same error.

          /e:
          Checking out a 1.7 working copy manually - to the target path - before the build starts (so, without jenkins),
          jenkins does run an update on the working copy, the checked out path.
          Going back to an older revision on the 1.7 working copy Jenkins does indeed update to HEAD.
          Just the new checkout to 1.7 workspace seems to fail.

          Show
          jk Jan Klass added a comment - - edited I just tried to check out a fresh copy, which did not succeed. The URI was a subpath of trunk, so not trunk itself. Checking out a fresh workspace because C:\jenkins\workspace\ProjName\MyFolder doesn't exist Cleaning local Directory MyFolder Checking out svn://srv/repopath/trunk/MyFolder ERROR: Failed to check out svn://srv/repopath/trunk/MyFolder org.tmatesoft.svn.core.SVNException: svn: E155007: 'C:\jenkins\workspace\ProjName\MyFolder ' is not a working copy Checking out to a 1.6 workspace instead of 1.7 worked with the same configuration. /e: Checking out trunk to a 1.7 workspace fails as well, same error. /e: Checking out a 1.7 working copy manually - to the target path - before the build starts (so, without jenkins), jenkins does run an update on the working copy, the checked out path. Going back to an older revision on the 1.7 working copy Jenkins does indeed update to HEAD. Just the new checkout to 1.7 workspace seems to fail.
          Hide
          kohsuke Kohsuke Kawaguchi added a comment -

          There has been and is a global configuration where you choose the working copy format version. So if the auto-upgrade is possible with SVNKit, I don't see any harm in doing so when this global configuration points to 1.7. The main problem right now for me is that I don't know how to make it happen.

          Jan, what is the Subversion server version? You said you saw that error while you were checking out to 1.7 workspace format? Also, please don't truncate the stack trace, because it is invaluable for me to understand where things failed.

          Show
          kohsuke Kohsuke Kawaguchi added a comment - There has been and is a global configuration where you choose the working copy format version. So if the auto-upgrade is possible with SVNKit, I don't see any harm in doing so when this global configuration points to 1.7. The main problem right now for me is that I don't know how to make it happen. Jan, what is the Subversion server version? You said you saw that error while you were checking out to 1.7 workspace format? Also, please don't truncate the stack trace, because it is invaluable for me to understand where things failed.
          Hide
          jk Jan Klass added a comment - - edited

          On the questions Kohsuke asked:

          When this error happens, do you have C:\Data\Jenkins\workspace\job\src\.svn? I step executed the code and it does create the workspace right before the code gets to here.

          No. Neither the .svn folder nor the folder it should be placed in is being created.
          Even if I create the target folder myself, no .svn folder is being created.

          The other experiment I'd like you to try is to use the scripting console, run "org.tmatesoft.svn.core.internal.wc.admin.SVNAdminAreaFactory.ourFactories;", and report back what you see. I wonder if someone else is setting that collection to empty, which would explain this.

          Result: [org.tmatesoft.svn.core.internal.wc.admin.SVNAdminArea16Factory@1b4d6c0, org.tmatesoft.svn.core.internal.wc.admin.SVNAdminArea15Factory@17f0649, org.tmatesoft.svn.core.internal.wc.admin.SVNAdminArea14Factory@75c229, org.tmatesoft.svn.core.internal.wc.admin.SVNXMLAdminAreaFactory@11e4232]

          Show
          jk Jan Klass added a comment - - edited On the questions Kohsuke asked: When this error happens, do you have C:\Data\Jenkins\workspace\job\src\.svn? I step executed the code and it does create the workspace right before the code gets to here. No. Neither the .svn folder nor the folder it should be placed in is being created. Even if I create the target folder myself, no .svn folder is being created. The other experiment I'd like you to try is to use the scripting console, run "org.tmatesoft.svn.core.internal.wc.admin.SVNAdminAreaFactory.ourFactories;", and report back what you see. I wonder if someone else is setting that collection to empty, which would explain this. Result: [org.tmatesoft.svn.core.internal.wc.admin.SVNAdminArea16Factory@1b4d6c0, org.tmatesoft.svn.core.internal.wc.admin.SVNAdminArea15Factory@17f0649, org.tmatesoft.svn.core.internal.wc.admin.SVNAdminArea14Factory@75c229, org.tmatesoft.svn.core.internal.wc.admin.SVNXMLAdminAreaFactory@11e4232]
          Hide
          jk Jan Klass added a comment -

          Here is the full stack trace. Path/Folder-names replaced.
          MyFolder1 is a 1.7 working copy I checked out manually before-hand.
          MyFolder2 is the Path it is supposed to check out as a 1.7 working copy.

          Gestartet durch Benutzer anonymous
          Baue auf Slave local2 in workspace c:\jenkins\workspace\Proj Name
          Updating svn://srv/path/ProjRepo/trunk/MyFolder1
          At revision 32522
          Checking out a fresh workspace because there's no workspace at C:\jenkins\workspace\Proj Name\MyFolder2
          Cleaning local Directory MyFolder2
          Checking out svn://srv/path/ProjRepo/trunk/MyFolder2
          ERROR: Failed to check out svn://srv/path/ProjRepo/trunk/MyFolder2
          org.tmatesoft.svn.core.SVNException: svn: E155007: 'C:\jenkins\workspace\Proj Name\MyFolder2' is not a working copy
          at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
          at org.tmatesoft.svn.core.internal.wc.admin.SVNAdminAreaFactory.open(SVNAdminAreaFactory.java:170)
          at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.doOpen(SVNWCAccess.java:379)
          at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.open(SVNWCAccess.java:283)
          at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.open(SVNWCAccess.java:276)
          at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.openAnchor(SVNWCAccess.java:171)
          at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:514)
          at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doCheckout(SVNUpdateClient16.java:965)
          at org.tmatesoft.svn.core.internal.wc2.old.SvnOldCheckout.run(SvnOldCheckout.java:19)
          at org.tmatesoft.svn.core.internal.wc2.old.SvnOldCheckout.run(SvnOldCheckout.java:8)
          at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
          at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1221)
          at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:292)
          at org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:781)
          at hudson.scm.subversion.CheckoutUpdater$1.perform(CheckoutUpdater.java:86)
          at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:144)
          at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:152)
          at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:121)
          at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:144)
          at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:789)
          at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:770)
          at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:753)
          at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2154)
          at hudson.remoting.UserRequest.perform(UserRequest.java:118)
          at hudson.remoting.UserRequest.perform(UserRequest.java:48)
          at hudson.remoting.Request$2.run(Request.java:287)
          at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
          at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
          at java.util.concurrent.FutureTask.run(Unknown Source)
          at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
          at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
          at hudson.remoting.Engine$1$1.run(Engine.java:60)
          at java.lang.Thread.run(Unknown Source)
          Caused by: svn: E155007: 'C:\jenkins\workspace\Proj Name\MyFolder2' is not a working copy
          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.wc.admin.SVNAdminAreaFactory.open(SVNAdminAreaFactory.java:165)
          ... 31 more
          FATAL: null
          java.lang.NullPointerException
          at java.util.ArrayList.addAll(Unknown Source)
          at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:743)
          at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:685)
          at hudson.model.AbstractProject.checkout(AbstractProject.java:1218)
          at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:586)
          at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:475)
          at hudson.model.Run.run(Run.java:1434)
          at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
          at hudson.model.ResourceController.execute(ResourceController.java:88)
          at hudson.model.Executor.run(Executor.java:239)

          Show
          jk Jan Klass added a comment - Here is the full stack trace. Path/Folder-names replaced. MyFolder1 is a 1.7 working copy I checked out manually before-hand. MyFolder2 is the Path it is supposed to check out as a 1.7 working copy. Gestartet durch Benutzer anonymous Baue auf Slave local2 in workspace c:\jenkins\workspace\Proj Name Updating svn://srv/path/ProjRepo/trunk/MyFolder1 At revision 32522 Checking out a fresh workspace because there's no workspace at C:\jenkins\workspace\Proj Name\MyFolder2 Cleaning local Directory MyFolder2 Checking out svn://srv/path/ProjRepo/trunk/MyFolder2 ERROR: Failed to check out svn://srv/path/ProjRepo/trunk/MyFolder2 org.tmatesoft.svn.core.SVNException: svn: E155007: 'C:\jenkins\workspace\Proj Name\MyFolder2' is not a working copy at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.admin.SVNAdminAreaFactory.open(SVNAdminAreaFactory.java:170) at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.doOpen(SVNWCAccess.java:379) at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.open(SVNWCAccess.java:283) at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.open(SVNWCAccess.java:276) at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.openAnchor(SVNWCAccess.java:171) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:514) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doCheckout(SVNUpdateClient16.java:965) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldCheckout.run(SvnOldCheckout.java:19) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldCheckout.run(SvnOldCheckout.java:8) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1221) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:292) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:781) at hudson.scm.subversion.CheckoutUpdater$1.perform(CheckoutUpdater.java:86) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:144) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:152) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:121) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:144) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:789) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:770) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:753) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2154) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:287) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at hudson.remoting.Engine$1$1.run(Engine.java:60) at java.lang.Thread.run(Unknown Source) Caused by: svn: E155007: 'C:\jenkins\workspace\Proj Name\MyFolder2' is not a working copy 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.wc.admin.SVNAdminAreaFactory.open(SVNAdminAreaFactory.java:165) ... 31 more FATAL: null java.lang.NullPointerException at java.util.ArrayList.addAll(Unknown Source) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:743) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:685) at hudson.model.AbstractProject.checkout(AbstractProject.java:1218) at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:586) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:475) at hudson.model.Run.run(Run.java:1434) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:239)
          Hide
          kohsuke Kohsuke Kawaguchi added a comment -

          I was ablt to reproduce Alexsei's problem by checking out from 1.7 subversion server to 1.7 working copy format via svn:// protocol.

          Looking into it.

          Show
          kohsuke Kohsuke Kawaguchi added a comment - I was ablt to reproduce Alexsei's problem by checking out from 1.7 subversion server to 1.7 working copy format via svn:// protocol. Looking into it.
          Hide
          kohsuke Kohsuke Kawaguchi added a comment -

          For those who are reporting issues with 1.40 RC, please also report:

          • version of the Subversion server (>=1.7 or <1.7?)
          • working copy format you set in the global configuration
          • Subversion access protocol
          Show
          kohsuke Kohsuke Kawaguchi added a comment - For those who are reporting issues with 1.40 RC, please also report: version of the Subversion server (>=1.7 or <1.7?) working copy format you set in the global configuration Subversion access protocol
          Hide
          kohsuke Kohsuke Kawaguchi added a comment - - edited

          Attached 1.40 RC2 built from rev.40558 in the repository. This version fixes the checkout failure problem with 1.7 server + 1.7 working copy.

          Show
          kohsuke Kohsuke Kawaguchi added a comment - - edited Attached 1.40 RC2 built from rev.40558 in the repository. This version fixes the checkout failure problem with 1.7 server + 1.7 working copy.
          Hide
          kohsuke Kohsuke Kawaguchi added a comment - - edited

          And this is 1.40 RC3 that fixes the "list tags/branches" parameter problem. From the repository revision 40560.

          Show
          kohsuke Kohsuke Kawaguchi added a comment - - edited And this is 1.40 RC3 that fixes the "list tags/branches" parameter problem. From the repository revision 40560.
          Hide
          jk Jan Klass added a comment - - edited

          On my RC1 problem: SVN version is 1.7 as well (thought you wanted a more specific version). Just as working copy format in global configuration, which is 1.7 as well. Accessed via svn protocol.

          Will try out the new RC.

          Show
          jk Jan Klass added a comment - - edited On my RC1 problem: SVN version is 1.7 as well (thought you wanted a more specific version). Just as working copy format in global configuration, which is 1.7 as well. Accessed via svn protocol. Will try out the new RC.
          Hide
          jk Jan Klass added a comment -

          RC3 checks out the 1.7 working copy just fine.
          The tag-listing seems to work fine as well, they are listed as described. Checking a selected tag out to a 1.7 working copy seems to work fine as well. (I did not try selecting from the repo root but from a tags/branches folder as we have them not in first path level of tags/branches.)

          Show
          jk Jan Klass added a comment - RC3 checks out the 1.7 working copy just fine. The tag-listing seems to work fine as well, they are listed as described. Checking a selected tag out to a 1.7 working copy seems to work fine as well. (I did not try selecting from the repo root but from a tags/branches folder as we have them not in first path level of tags/branches.)
          Hide
          jk Jan Klass added a comment -

          Thank you very much for your work,
          looking forward to the release!

          Show
          jk Jan Klass added a comment - Thank you very much for your work, looking forward to the release!
          Hide
          kohsuke Kohsuke Kawaguchi added a comment -

          Released as 1.40.

          Show
          kohsuke Kohsuke Kawaguchi added a comment - Released as 1.40.
          Hide
          pancake pancake added a comment -

          Please take a look at JENKINS-13835.

          Show
          pancake pancake added a comment - Please take a look at JENKINS-13835 .
          Hide
          ntumba ntumba lobo added a comment -

          Thank for the work on this issue.
          I would benefit from it but I dont understand the release number mentioned by Kohsuke Kawaguchi 1.40.
          What does it refer to ? Our current Jenkins version is already 1.447.

          Show
          ntumba ntumba lobo added a comment - Thank for the work on this issue. I would benefit from it but I dont understand the release number mentioned by Kohsuke Kawaguchi 1.40. What does it refer to ? Our current Jenkins version is already 1.447.
          Hide
          brenuart brenuart added a comment -

          I would benefit from it but I dont understand the release number mentioned by Kohsuke Kawaguchi 1.40.

          1.40 is the version of the Subversion Plugin. Go into "Manage Jenkins"->"Manage Plugins": the "Installed" tab lists the plugins installed on your instance and their corresponding versions.

          Show
          brenuart brenuart added a comment - I would benefit from it but I dont understand the release number mentioned by Kohsuke Kawaguchi 1.40. 1.40 is the version of the Subversion Plugin . Go into "Manage Jenkins"->"Manage Plugins": the "Installed" tab lists the plugins installed on your instance and their corresponding versions.
          Hide
          shanz1999 Duncan Perrett added a comment -

          I found it a bit confusing as the subversion plugin is one that is bundled with jenkins.
          However, the latest jenkins.war bundle includes a much older version of the subversion plugin so you need to manually update it.
          (I don't know when/if the bundled version will ever reach 1.40).
          I think this is called 'pinning' the plugin.

          Show
          shanz1999 Duncan Perrett added a comment - I found it a bit confusing as the subversion plugin is one that is bundled with jenkins. However, the latest jenkins.war bundle includes a much older version of the subversion plugin so you need to manually update it. (I don't know when/if the bundled version will ever reach 1.40). I think this is called 'pinning' the plugin.
          Hide
          diane_wills Diane Wills added a comment -

          I'm still not able to update Jenkins to use the Subversion Plugin 1.40. I'm using Jenkins 1.466 on Windows Server 2008. I tried manually updating the Subversion files and writing the empty file Subversion.jpi.pinned to $(JENKINS_HOME)/plugins, but that didn't work; the files got overwritten anyways to the old version.

          Since there are no plans to add Subversion 1.40 to Jenkins permanently, can someone help me?

          Show
          diane_wills Diane Wills added a comment - I'm still not able to update Jenkins to use the Subversion Plugin 1.40. I'm using Jenkins 1.466 on Windows Server 2008. I tried manually updating the Subversion files and writing the empty file Subversion.jpi.pinned to $(JENKINS_HOME)/plugins, but that didn't work; the files got overwritten anyways to the old version. Since there are no plans to add Subversion 1.40 to Jenkins permanently, can someone help me?
          Hide
          rvillanu Richard Villanueva added a comment -

          It is not resolved

          Show
          rvillanu Richard Villanueva added a comment - It is not resolved
          Hide
          rvillanu Richard Villanueva added a comment -

          It is not resolved

          Show
          rvillanu Richard Villanueva added a comment - It is not resolved
          Hide
          depe Denis Eperonnier added a comment - - edited

          I noticed something strange using Subversion Plugin 1.40, together with Jenkins 1.467.
          Some time after the upgrade from plugin 1.39, there were some errors when trying to update a slave workspace:

          org.tmatesoft.svn.core.SVNException: svn: E175002: REPORT /svn/xxxxxxxxxx/!svn/vcc/default failed
          at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:304)
          at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:289)
          at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:277)
          at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:696)
          at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:328)
          at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.runReport(DAVRepository.java:1289)
          at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.update(DAVRepository.java:837)
          at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:557)
          at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:414)
          at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:324)
          at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27)
          at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11)
          at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
          at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1221)
          at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:292)
          at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:315)
          at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:295)
          at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:391)
          at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:136)
          at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:144)
          at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:789)
          at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:770)
          at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:753)
          at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2180)
          at hudson.remoting.UserRequest.perform(UserRequest.java:118)
          at hudson.remoting.UserRequest.perform(UserRequest.java:48)
          at hudson.remoting.Request$2.run(Request.java:287)
          at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
          at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
          at java.util.concurrent.FutureTask.run(Unknown Source)
          at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
          at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
          at hudson.remoting.Engine$1$1.run(Engine.java:60)
          at java.lang.Thread.run(Unknown Source)
          Caused by: svn: E175002: REPORT /svn/xxxxxxxx/!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)
          ... 34 more
          no change for http://xxxxxxxxx since the previous build

          So I checked svn server log, and I could see that my master node uses the latest SVNKit 1.7.4 ("SVN/1.7.4 SVNKit/1.7.4-jenkins-1 (http://svnkit.com/) t20120507_1224"), but one of my slaves is using an older version ("SVN/1.7.0 SVNKit/1.7.0-dev (http://svnkit.com/) rSNAPSHOT"), can this explain my issue?

          edit: I forgot to mention, my svn server is 1.5, and working copy format is configured as 1.5

          Show
          depe Denis Eperonnier added a comment - - edited I noticed something strange using Subversion Plugin 1.40, together with Jenkins 1.467. Some time after the upgrade from plugin 1.39, there were some errors when trying to update a slave workspace: org.tmatesoft.svn.core.SVNException: svn: E175002: REPORT /svn/xxxxxxxxxx/!svn/vcc/default failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:304) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:289) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:277) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:696) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:328) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.runReport(DAVRepository.java:1289) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.update(DAVRepository.java:837) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:557) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:414) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:324) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1221) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:292) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:315) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:295) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:391) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:136) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:144) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:789) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:770) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:753) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2180) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:287) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at hudson.remoting.Engine$1$1.run(Engine.java:60) at java.lang.Thread.run(Unknown Source) Caused by: svn: E175002: REPORT /svn/xxxxxxxx/!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) ... 34 more no change for http://xxxxxxxxx since the previous build So I checked svn server log, and I could see that my master node uses the latest SVNKit 1.7.4 ("SVN/1.7.4 SVNKit/1.7.4-jenkins-1 ( http://svnkit.com/ ) t20120507_1224"), but one of my slaves is using an older version ("SVN/1.7.0 SVNKit/1.7.0-dev ( http://svnkit.com/ ) rSNAPSHOT"), can this explain my issue? edit: I forgot to mention, my svn server is 1.5, and working copy format is configured as 1.5
          Hide
          kohsuke Kohsuke Kawaguchi added a comment -

          Richard, Denis, if you see issues with Subversion plugin, please open a separate ticket instead of reopening this.

          This ticket was to track the integration of SVNKit 1.7 that brings in Subversion 1.7 compatibility, and that work is completed. In the event that this work introduced issues, please use a separate ticket, so that we can track issues better. Thanks!

          Show
          kohsuke Kohsuke Kawaguchi added a comment - Richard, Denis, if you see issues with Subversion plugin, please open a separate ticket instead of reopening this. This ticket was to track the integration of SVNKit 1.7 that brings in Subversion 1.7 compatibility, and that work is completed. In the event that this work introduced issues, please use a separate ticket, so that we can track issues better. Thanks!

            People

            • Assignee:
              kohsuke Kohsuke Kawaguchi
              Reporter:
              soundworker soundworker
            • Votes:
              108 Vote for this issue
              Watchers:
              96 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: