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
    1. subversion.hpi
      4.12 MB
      Kohsuke Kawaguchi
    2. subversion.hpi
      4.12 MB
      Kohsuke Kawaguchi
    3. subversion.hpi
      4.12 MB
      Kohsuke Kawaguchi

      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: