How to use different SVN workspace version on a slave?

[Fritz Elfert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

In the global config, the SVN workspace version can be selected. However
I have a mix of older/newer slave where some use 1.7 natively and some
others use still 1.6. I can't find any way to select the workspace
version per slave - which is a prerequisite for using some tools (svn2cl
specifically) from a shell during build.

Am I missing something here? (IMHO, the SVN workspace version should be
configurable per node....)

Thanks for any hints,
-Fritz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlAcJuMACgkQboM4mAMyprAETgCdHUvGIGwdys8J+31BamYzlnfd
shcAmgLuRxSl1Ow2sl3CXDZvInobBES2
=wiUt
-----END PGP SIGNATURE-----

[Michael Pailloncy]

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

[Fritz Elfert]

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

[Michael Pailloncy]

Le 03/08/2012 22:44, Fritz Elfert a �crit :

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.

[Qazwart]

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 <mpap...@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:

>>> Michaël Pailloncy

[Fritz Elfert]

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

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

[Fritz Elfert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/03/2012 11:44 PM, Michael Pailloncy wrote:

[...]

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

No, the job config is not a good idea. Imagine several slaves with
different svn installations and a job which is not pinned (can build
anywhere). The correct place is the node config. Just like the
tools-locations that already can be configured per node.

- -Fritz

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlAcXjMACgkQboM4mAMyprCTFgCfcqXMIChuLnQmvwj3LWfuXBO+
VX0An2PgMu/OPFGZVHtEGLDvug7GG9qt
=6kwc
-----END PGP SIGNATURE-----