[jira] [Issue Comment Edited] (INFRA-4521) Jenkins-built in SVN (Tmatesoft, 1.6 compatible) conflicts with system-installed SVN (1.7) on the upgraded FreeBSD slaves for some builds

["Uwe Schindler (Issue Comment Edited) (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/INFRA-4521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13224206#comment-13224206 ] 

Uwe Schindler edited comment on INFRA-4521 at 3/7/12 11:36 AM:
---------------------------------------------------------------

I have a "good solution" to the problem:
I reinstalled the original binary FreeBSD package of subversion 1.7 from tb.apache.org, so upgrades should work without conflicts or other problems.
Instead of compiling a static version of native SVN, I downloaded svnkit 1.7-beta3, extracted it to the jenkins-tools folder and used our ANT coniguration to use the "CLI" versions of svnkit to do the tasks. This works fine, as the jsvn and jsvnversion are compatible to the originals. The cool thing is, that in contrast to original SVN, svnkit can handle all types of checkout, so once Jenkins upgrades to later version of svnkit, the build still runs.

The last build was triggered like that:

/home/hudson/tools/ant/latest1.7/bin/ant -Dversion=4.0-2012-03-07_11-01-08 -Dsvnversion.exe=/home/hudson/tools/svn/svnkit/bin/jsvnversion -Dsvn.exe=/home/hudson/tools/svn/svnkit/bin/jsvn clean package-tgz-src package-tgz

I think thats a good solution for now. My comment from earlier that we have to bundle svnkit with our src repository is no longer valid, as we use the "emulated cli" from svnkit as replacement to native svn.
                
      was (Author: thetaphi):
    I have a "good solution" to the problem:
I reinstalled the original binary FreeBSD package of subversion 1.7 from tb.apache.org, so upgrades should work without conflicts or other problems.
Instead of compiling a static version of native SVN, I downloaded svnkit 1.7-beta3, extracted it to the jenkins-tools folder and used our ANT coniguration to use the "CLI" versions of svnkit to do the tasks. This works fine, as the jsvn and jsvnversion are compatible to the originals. The cool thing is, that in contrast to original SVN, svnkit can handle all types of checkout, so once Jenkins upgrades to later version of svnkit, the build still runs.

The last build was triggered like that:
{noformat}
/home/hudson/tools/ant/latest1.7/bin/ant -Dversion=4.0-2012-03-07_11-01-08 -Dsvnversion.exe=/home/hudson/tools/svn/svnkit/bin/jsvnversion -Dsvn.exe=/home/hudson/tools/svn/svnkit/bin/jsvn clean package-tgz-src package-tgz
{noformat}

I think thats a good solution for now. My comment from earlier that we have to bundle svnkit with our build is no longer valid, as we use the "emulated cli" from svnkit as replacement to native svn.
                  
> Jenkins-built in SVN (Tmatesoft, 1.6 compatible) conflicts with system-installed SVN (1.7) on the upgraded FreeBSD slaves for some builds
> -----------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: INFRA-4521
>                 URL: https://issues.apache.org/jira/browse/INFRA-4521
>             Project: Infrastructure
>          Issue Type: Bug
>      Security Level: public(Regular issues) 
>          Components: Jenkins
>         Environment: FreeBSD 9 Jail, lucene.zones.apache.org
>            Reporter: Uwe Schindler
>
> Yesterday the FreeBSD slave of Lucene was upgraded (lucene.zones.apache.org). It is used as build machine for Apache Lucene and Solr. By this upgrade to FreeBSD 9, the ports collection was also upgraded and now uses Subversion 1.7 as default.
> The Lucene builds running under Jenkins are checked out using the Jenkins-internal SVN client (Java-based, by Tmatesoft, 1.6 compatible). This is not really a problem at all, unless the build script itsself uses subversion to detect e.g. the revision number to put it into the manifest file of built jars (for that case we have a fallback: it only does this if it suceeds, otherwise the version number is undefined). But in our case the revno is also needed to do an "svn export" of the original source tree to package the SRC JAR. For that the SVN revision is mandatory, and failing to get them is a problem for our builds.
> The problem is simple: The SVN checkout our build is started from Jenkins is Subversion 1.6, but the build tools used by the scripts are Subversion 1.7. We also upgraded the svn checkouts done by Jenkins, but of course on the next build it will detect the wrong checkout version and nuke it, and re-checkout with 1.6.
> For now we solved the problem on *our* Jenkins slave by make deinstall of /usr/ports/devel/subversion and installing /usr/ports/devel/subversion16.
> The points for discussion:
> - Is there any plan to upgrade Jenkins itsself to also use Subversion 1.7 internally?
> - If so, we should get informed before the upgrade to revert the above ports installation/deinstallation
> - If Jenkins stays with Tmatesoft Subversion 1.6, we need a plan for later upgrades of FreeBSD

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira