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

allow to set subversion workspace version per slave

    XMLWordPrintable

    Details

    • Type: New Feature
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: subversion-plugin
    • Labels:
      None
    • Environment:
      windows/linux
    • Similar Issues:

      Description

      Hi,

      we have a computer lab full of mixed machines and different subversion client versions (most of them with 1.6, but also a few where we need 1.7)

      currently we can't set a different workspace version. Our build-tools use internally the host subversion client. Because of the incompatibility between 1.6 and 1.7, those tools can't read the 1.6 format without upgrade, and jenkins can't read the 1.7 format if we do so.

      a really nice feature would be if we could set the subversion workspace format/version for each jenkins-slave.

        Attachments

          Issue Links

            Activity

            Hide
            paleozogt Aaron Simmons added a comment -

            The workaround is not necessarily trivial. As the OP says, "Our build-tools use internally the host subversion client. Because of the incompatibility between 1.6 and 1.7, those tools can't read the 1.6 format without upgrade."

            I had this same problem at my previous company. We had ~50 different build machine projects that all needed to get upgraded, just because Jenkins couldn't support multiple slave svn versions.

            Show
            paleozogt Aaron Simmons added a comment - The workaround is not necessarily trivial. As the OP says, "Our build-tools use internally the host subversion client. Because of the incompatibility between 1.6 and 1.7, those tools can't read the 1.6 format without upgrade." I had this same problem at my previous company. We had ~50 different build machine projects that all needed to get upgraded, just because Jenkins couldn't support multiple slave svn versions.
            Hide
            danielbeck Daniel Beck added a comment -

            Possible alternative would be to use the jsvn command line client distributed as part of SVNKit. Even less installation needed (assuming you're allowed to run basic Java tools).

            Show
            danielbeck Daniel Beck added a comment - Possible alternative would be to use the jsvn command line client distributed as part of SVNKit. Even less installation needed (assuming you're allowed to run basic Java tools).
            Hide
            danielbeck Daniel Beck added a comment -

            I have to disagree that the workaround stated is easy to implement.

            It is easy to implement. It just goes against your organization's self-imposed rules, which is a very different problem. (I'm not dismissing it, see previous comment, but a distinction should still be made.)

            Show
            danielbeck Daniel Beck added a comment - I have to disagree that the workaround stated is easy to implement. It is easy to implement. It just goes against your organization's self-imposed rules, which is a very different problem. (I'm not dismissing it, see previous comment, but a distinction should still be made.)
            Hide
            dan_smartstream dan russell added a comment -

            Was looking for something similar where you could specify the subversion version in the same way you would a jdk.

            I have recently updated our jenkins and servers to use svn 1.8, but we have some older builds that need hotfixes that use svnkit and ant, which are currently 1.5

            Obviously easier to switch subversion version on a server than it is to update an unknown number of branches/tags with a newer svn version.

            Show
            dan_smartstream dan russell added a comment - Was looking for something similar where you could specify the subversion version in the same way you would a jdk. I have recently updated our jenkins and servers to use svn 1.8, but we have some older builds that need hotfixes that use svnkit and ant, which are currently 1.5 Obviously easier to switch subversion version on a server than it is to update an unknown number of branches/tags with a newer svn version.
            Hide
            vinny Vincent Furia added a comment -

            I've been having the same problem. The workaround I'm using is to set the svn version in the jenkins plugin to the lowest version I use. Then I call "svn upgrade" as the first step of my build process. (Really, I check for an error from svn info, then upgrade if needed). Apparently svnkit is tolerant of dealing with different subversion versions regardless of how it is configured in jenkins. After the ugprade, jenkins can still perform an update.

            Show
            vinny Vincent Furia added a comment - I've been having the same problem. The workaround I'm using is to set the svn version in the jenkins plugin to the lowest version I use. Then I call "svn upgrade" as the first step of my build process. (Really, I check for an error from svn info, then upgrade if needed). Apparently svnkit is tolerant of dealing with different subversion versions regardless of how it is configured in jenkins. After the ugprade, jenkins can still perform an update.

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              flow86 Florian Doersch
              Votes:
              31 Vote for this issue
              Watchers:
              29 Start watching this issue

                Dates

                Created:
                Updated: