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

allow to set subversion workspace version per slave

    • Icon: New Feature New Feature
    • Resolution: Unresolved
    • Icon: Major Major
    • subversion-plugin
    • None
    • windows/linux

      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.

          [JENKINS-14157] allow to set subversion workspace version per slave

          Fritz Elfert added a comment -

          +1 from me. The global setting is pretty useless in a mixed environment. It should move to the node and the main setting might be serve as a default for new nodes.

          Fritz Elfert added a comment - +1 from me. The global setting is pretty useless in a mixed environment. It should move to the node and the main setting might be serve as a default for new nodes.

          +1 for me too. With support for Subversion 1.8 being a much requested feature (JENKINS-18935) we'll have the same problem again because the workspace format changed again from 1.7 to 1.8.

          Gustavo Chaves added a comment - +1 for me too. With support for Subversion 1.8 being a much requested feature ( JENKINS-18935 ) we'll have the same problem again because the workspace format changed again from 1.7 to 1.8.

          Hi all,

          Any progress on this?

          We would really appreciate this!
          Our environment is suffering a lot from this issue!

          1. We have build servers running many different subversion client versions (1.5 - 1.7)
          2. Many of our Job's build steps invoke command-line svn for several tasks
          3. We have Jobs that explicitly require subversion >=1.7, while we MUST keep the global subversion to 1.6 (because of previous point)
          4. Our current workaround uses svn upgrade when an svn command fails, but:
            • This only works for some of the issues
            • requires a lot of maintenance, taking very much of our precious time!

          So, I would like to increase priority on this issue.

          Thanks in advance!

          Tom Ghyselinck added a comment - Hi all, Any progress on this? We would really appreciate this! Our environment is suffering a lot from this issue! We have build servers running many different subversion client versions (1.5 - 1.7) Many of our Job's build steps invoke command-line svn for several tasks We have Jobs that explicitly require subversion >=1.7 , while we MUST keep the global subversion to 1.6 (because of previous point) Our current workaround uses svn upgrade when an svn command fails, but: This only works for some of the issues requires a lot of maintenance , taking very much of our precious time! So, I would like to increase priority on this issue. Thanks in advance!

          Daniel Beck added a comment -

          Reducing priority, as workaround is obvious and easy to implement: Install a Subversion version compatible with Jenkins workspace version setting on all machines.

          Daniel Beck added a comment - Reducing priority, as workaround is obvious and easy to implement: Install a Subversion version compatible with Jenkins workspace version setting on all machines.

          alex mattern added a comment -

          @Daniel Beck I have to disagree that the workaround stated is easy to implement. The servers running Jenkins nodes are not under my control. Due to firm policy, only the OS supported version may be installed. With servers running multiple operating systems, the subversion versions are varied.

          There is a less obvious workaround. Configure each application that Jenkins calls, such as Maven, a shell script or command-line svn, to use an jar version of subversion that matches the version Jenkins is using.

          In Maven I have configured a plugin like this:
          <plugin>
          <artifactId>maven-release-plugin</artifactId>
          <version>2.2.2</version>
          <configuration>
          <tagBase>${svn.base}/tags</tagBase>
          <providerImplementations>
          <svn>javasvn</svn>
          </providerImplementations>
          </configuration>
          <dependencies>
          <dependency>
          <groupId>com.google.code.maven-scm-provider-svnjava</groupId>
          <artifactId>maven-scm-provider-svnjava</artifactId>
          <version>2.1.1</version>
          <scope>compile</scope>
          </dependency>
          </dependencies>
          </plugin>

          alex mattern added a comment - @Daniel Beck I have to disagree that the workaround stated is easy to implement. The servers running Jenkins nodes are not under my control. Due to firm policy, only the OS supported version may be installed. With servers running multiple operating systems, the subversion versions are varied. There is a less obvious workaround. Configure each application that Jenkins calls, such as Maven, a shell script or command-line svn, to use an jar version of subversion that matches the version Jenkins is using. In Maven I have configured a plugin like this: <plugin> <artifactId>maven-release-plugin</artifactId> <version>2.2.2</version> <configuration> <tagBase>${svn.base}/tags</tagBase> <providerImplementations> <svn>javasvn</svn> </providerImplementations> </configuration> <dependencies> <dependency> <groupId>com.google.code.maven-scm-provider-svnjava</groupId> <artifactId>maven-scm-provider-svnjava</artifactId> <version>2.1.1</version> <scope>compile</scope> </dependency> </dependencies> </plugin>

          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.

          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.

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

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

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

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

          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.

          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.

          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.

          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.

            Unassigned Unassigned
            flow86 Florian Doersch
            Votes:
            32 Vote for this issue
            Watchers:
            29 Start watching this issue

              Created:
              Updated: