-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/04/2012 12:00 AM, Qazwart wrote: > 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? > Because if svn commandline-tools are used during the build process, those fail if svn's metadata in the slave's workspace does not match the commandline-tool's version. If you just talk java/maven/ant it almost never is a problem, but if you talk C/C++/GNU-autotools, using commandline-tools is pretty common - e.g.: Generating a debian (or RPM) changelog as part of automated package-generation.
> -- > David Weintraub > [email protected] > > On Aug 3, 2012, at 5:44 PM, Michael Pailloncy <[email protected]> wrote: > >> Le 03/08/2012 22:44, Fritz Elfert a écrit : > 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 >>>>> >>>>> >> >> 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. >> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAcXGkACgkQboM4mAMyprBJqgCgm1kBtNn/Xb5wTKQsFq+T2WI7 lh0Anj22Oi1LbYH6lEszaZR2d3fAlb3K =U15j -----END PGP SIGNATURE-----
