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

          Florian Doersch created issue -

          Marco Borm added a comment -

          I have the same problem. I have to downgrade ALL used clients including TortoiseSVN on the development machines now, so the jenkins WC revision matches always the installed subversion client, or install unofficial subversion packages on the build machines.

          Marco Borm added a comment - I have the same problem. I have to downgrade ALL used clients including TortoiseSVN on the development machines now, so the jenkins WC revision matches always the installed subversion client, or install unofficial subversion packages on the build machines.

          Same for me, I have about 20 nodes running on 10 different machines. Some machines are also used as development machines. Plus, I would like to update them to SVN 1.7 step by step in order to test one node before possibly breaking the entire system. So an option to set the SVN version per slave would be really helpful.

          Martin Obermeir added a comment - Same for me, I have about 20 nodes running on 10 different machines. Some machines are also used as development machines. Plus, I would like to update them to SVN 1.7 step by step in order to test one node before possibly breaking the entire system. So an option to set the SVN version per slave would be really helpful.

          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.
          kutzi made changes -
          Link New: This issue is related to JENKINS-14690 [ JENKINS-14690 ]
          Gustavo Chaves made changes -
          Link New: This issue is duplicated by JENKINS-19714 [ JENKINS-19714 ]

          +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!
          Tom Ghyselinck made changes -
          Priority Original: Major [ 3 ] New: Critical [ 2 ]
          Daniel Beck made changes -
          Issue Type Original: Improvement [ 4 ] New: New Feature [ 2 ]

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

              Created:
              Updated: