4

I have been having problem with the new update to subversion 1.7 vs the use of Jenkins.

Here is the deal, a few people in our company switch to the new subversion 1.7, therefore they cannot revert to the old 1.6 subversion folder structure (unless they commit everything erase their folder, uninstall the new 1.7 subversion with all their cool new feature, install the old and boring 1.6 and re-export everything, I know).

So considering the fact that want to move forward and use the new feature of subversion 1.7 such as having externals that can easily use revision number..., I now have a problem with jenkins.

The option I have for Jenkins is to use the pluggins for SVNKIT 1.3.7 or can be update to 1.3.9. If we look at the download page for SVNKIT ( http://svnkit.com/download.php ) they say that the version 1.3.7 and 1.3.9 is incompatible with Subversion 1.7. This should be fix around march 2012. My server have to be up and running asap so I cannot wait 1 whole month.

So what would be your suggestion for me to try to have my user use Subversion 1.7 and that I could still be using Jenkins.

FYI I tried the following :

  • Changing the protocol used on the server, using protocol SSLv3 make Subversion work but fail jenkins, and using TLSv1 and SSLv3 make jenkins work but fail some subversion operation, so no positive result.
  • Changing the protocol option in jenkins to use SSLv3, this was mention in a few faq that by default jenkins use protocol TLSv1, still no positive result. (Always give me the error Unable to access https://svn.myrepos.com/svn/teamlib/package/ThePackages/trunk : svn: OPTIONS /svn/teamlib/package/ThePackages/trunk failed (show details) (Maybe you need to enter credential?))
  • Making a new repository on another server that use TLSv1 and SSLv3, this repository would only contain an external link to the real basic repository ( example the new repository https://svn2.myrepos.com/svn/teamlib/testpackage/trunk this only contain an external to the svn on the other server using only SSLv3 https://svn.myrepos.com/svn/teamlib/package/ThePackages/trunk ).

The latest is the closest I have been to a success since Jenkins work fine to build everything but seem to be unable to export externals. (I am able though to do the export manually but I would need that to be done by jenkins).

So any thought?

wincrasher
  • 121
  • 1
  • 10

2 Answers2

3

I'm not sure I understand your architecture. Your developers can continue to use 1.7 on their development machines (clients) even if the repository is running subversion 1.6.x. To my knowledge, the improved external support was introduced before 1.7, e.g. we use pegged externals in 1.6.x. In my opinion, compatibility with Jenkins trumps any benefits of running 1.7 on the server.

We run a central svn server running subversion 1.6.x (which supports pegged revision externals) and some developers have upgraded to subversion 1.7 clients on their development machines. Because the svn server is running 1.6.x, Jenkins can check out from our central repository (including checking out externals). I would recommend sticking with 1.6.x on your repository until Jenkins/SvnKit supports 1.7.

The Subversion 1.7 release notes say that the repository format has not changed, so you should be able to downgrade your repository if you've already upgraded:

Subversion 1.7 servers use the same repository format as Subversion 1.6. Therefore, it is possible to seamlessly upgrade and downgrade between 1.6.x and 1.7.x servers without changing the format of the on-disk repositories. (This is not correct in general for any pair of 1.x and 1.y servers, but happens to hold for 1.6 and 1.7.) If new 1.7 features were enabled on the server (in the hooks or server configuration files), they will, of course, have to be disabled prior to reverting back to a 1.6 server.

Dave Bacher
  • 15,652
  • 3
  • 63
  • 86
0

You will have to wait until the subversion plugin for Jenkins is updated to support Subversion 1.7. I am not sure when that will be. The development on the Hudson Subversion Plugin to upgrade is currently ongoing and should be available in the next release of the plugin.

Manfred Moser
  • 29,539
  • 13
  • 92
  • 123