Can't use jenkins and Subversion 1.7? Any solution?

Question

I am having a problem with the new subversion 1.7 update against using Jenkins.

Here's the thing: several people in our company are switching to the new subversion 1.7, so they can’t go back to the old subversion 1.6 folder structure (unless they do everything, erase their folder, delete the new 1.7 subversion with all their cool new function , install the old and boring 1.6 and re-export everything, I know).

So, given the fact that you want to move forward and use the new subversion 1.7 function, for example, to have external elements that can easily use the version number ..., I now have a problem with jenkins.

The option I have for Jenkins is to use pluggins for SVNKIT 1.3.7 or can be upgraded to 1.3.9. If we look at the SVNKIT download page ( http://svnkit.com/download.php ), then they say that versions 1.3.7 and 1.3.9 are not compatible with Subversion 1.7. This should be fixed in March 2012. My server should work and work as soon as possible, so I can not wait 1 month.

So, what would you advise me to try using Subversion 1.7 and that I can still use Jenkins.

FYI I tried the following:

• Changing the protocol used on the server using SSLv3 makes Subversion work, but jenkins does not work, and using TLSv1 and SSLv3 does jenkins work, but does not perform some subversion operation, so there will be no positive result.
• Changing the protocol option in jenkins to use SSLv3, it has been mentioned in several cases that jenkins use the TLSv1 protocol by default, but there is still no positive result. (Always give me an error. Unable to access https://svn.myrepos.com/svn/teamlib/package/ThePackages/trunk : svn: OPTIONS / svn / teamlib / package / ThePackages / trunk failed (show details) (Maybe do you need to enter credentials?))
• When creating a new repository on another server using TLSv1 and SSLv3, this repository will only contain an external link to the real base repository (for example, the new repository https://svn2.myrepos.com/svn/teamlib/testpackage/trunk contains only the external svn file on another server using only SSLv3 https://svn.myrepos.com/svn/teamlib/package/ThePackages/trunk ).

The last thing closest is that I succeeded, as Jenkins works just fine to build everything, but doesn't seem to be able to export external resources. (I can do the export manually, but I need this to be done by jenkins).

So any thought?

Answer 1

I'm not sure I understand your architecture. Your developers can continue to use 1.7 on their development machines (clients), even if subversion 1.6.x is running in the repository. As far as I know, improved external support has been introduced up to 1.7, for example. we use anchored external elements in 1.6.x. In my opinion, compatibility with Jenkins exceeds all the advantages of working with 1.7 on the server.

We run a central svn server running subversion 1.6.x (which supports bound external audits), and some developers have upgraded to subversion 1.7 clients on their development machines. Since the svn server is running 1.6.x, Jenkins can check our central repository (including checking external resources). I would recommend sticking to 1.6.x in your repository until Jenkins / SvnKit supports 1.7.

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

Subversion 1.7 servers use the same repository format as Subversion 1.6. Thus, it is possible to smoothly update and lower ratings between 1.6.x and 1.7.x servers without changing the format on disk repositories. (This is not entirely correct for any pair of 1.x and 1.y, but, as a rule, for 1.6 and 1.7.) If new functions 1.7 were enabled on the server (in the intercepts or on the server, configuration files), they should be disconnected earlier to return to server 1.6.

Answer 2

You will need to wait until the subversion plugin for Jenkins is updated to support Subversion 1.7. I am not sure when it will be. The development of the Subdersion plugin for Hudson for the upgrade is currently ongoing and should be available in the next version of the plugin.