I'm a bit confused by this. All Subversion 1.1 to 1.7 clients should work with all Subversion servers from 1.1 and up.
Besides Jenkins doesn't use the command line clients. It uses SvnKit. Why is the version of the Subversion client so important? Are you shipping or sharing working directories between slaves and the master? -- David Weintraub da...@weintraub.name On Aug 3, 2012, at 5:44 PM, Michael Pailloncy <mpapo....@gmail.com> wrote: > Le 03/08/2012 22:44, Fritz Elfert a écrit : >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi Michael, >> >> On 08/03/2012 10:00 PM, Michael Pailloncy wrote: >>> Le 03/08/2012 21:30, Fritz Elfert a écrit : >>>> I can't find any way to select the workspace >>>> version per slave >>> Hi, >>> I'm not sure to clearly understand what you want. >>> If you have slaves with SVN 1.7 and slaves with 1.6 natively, you can >>> add labels like "svn1-6" to nodes with 1.6 version and "svn1-7" to >>> those with version 1.7. >> Suppose, I did label them, how would I tell jenkins to use different SVN >> workspace per slave if there is only one global setting in jenkins' >> config? (There's nothing configurable in the node setup GUI). >> >> Perhaps more lengthly but clearly: >> >> I have several Fedora17 hosts which come with svn-1.7, so in Jenkins' >> global setting, I select 1.7. Now I have to build some projects for >> older targets (RHEL6) as well. The RHEL6 slaves use svn-1.6 (there's no >> official svn-1-7 package for RHEL6 - and frankly, i don't want to >> install something "custom" on those, because that should be a clean >> install). When I create a new job (pinned to RHEL6 of course) Jenkins >> still does the checkout using svn-1.7 and later in the build itself the >> commandline svn complains (rightfully) about the wrong svn version. If I >> switch to 1.6 globally, the situation is reverse: RHEL6 slaves build >> fine, but commandline-tools on Fedora17 complain. >> >> So: >> The global setting is useful as a *default* at best but should be >> overridable per slave. (or perhaps an option to delegate checkout+update >> to cmdline binaries on the slave would do). >> >> In the meantime, I found out that there's an issue for this in JIRA already: >> https://issues.jenkins-ci.org/browse/JENKINS-14157 >> Unfortunately, it's still unassigned. >> >> >>> So you can use the correct version depending on your job requirements. >>> >>> But I think the best way would be to install both versions on all slaves. >>> >>> Michaël Pailloncy >>> >>> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.12 (GNU/Linux) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> iEUEARECAAYFAlAcOEUACgkQboM4mAMyprAdCgCfYvclqpnawNU/K1+YuaP5WWnd >> hOIAlRvnXIK2/6DOJGBTVSk3c/DOlzo= >> =77eO >> -----END PGP SIGNATURE----- > > Ok ! I've misunderstand. It could be nice to add more than one SVN > installation path like we can with Java, Maven, Git, .. and permit to choose > it in job configuration. >
