3
votes

I am trying now for almost 2 days to get the release plugin running with maven and hudson. I installed now a svn client(dont know why I needed to this as Hudson has a SVN plugin) and the plugin is able to run "mvn" commands. Now after restarting hudson and the job I am getting the following error:

org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.0:prepare (default-cli) on project framework: Unable to check for local modifications Provider message: The svn command failed. Command output: svn: E155036: Please see the 'svn upgrade' command svn: E155036: Working copy 'C:.hudson\jobs\Project 1\workspace' is too old (format 8, created by Subversion 1.4)

What I am doing wrong here? It looks like I am using this plugin heavily wrong as I am stepping from one error into another.

Thanks for your help!

3

3 Answers

2
votes

Working copies in SVN are based on the version of the svn client you use. Over time these can be incompatible (which is ok, as they always give you an easy-upgrade system, usually this occurs automatically), however going from sVN v 1.4 to the latest (1.7) will not give you the usual auto-upgrade loveliness. In fact, getting the original checkout done using svn 1.4 is probably a bad idea anyway as that is ancient.

So, you need to find out what is doing the original checkout. If its the plugin, then dump it. I don't think the current version of Hudson has such an old svn client, even if they haven't upgraded it to 1.7 yet, it'll be on 1.6.x at the very least.

Check the maven plugin to see how old that is, and the svn plugin (and your hudson install).

2
votes

Having just dealt with Maven releases in Jenkins, I feel your pain.

Others have already answered your question: you'll need to make sure all your SVN clients working with the same working copy are the same version.

But to answer your meta-question of why you need a command-line SVN client, it's because the maven-release-plugin doesn't just pull data down from SVN, it actually has to commit and tag revisions, and Hudson doesn't provide a mechanism for that. Additionally, maven-release-plugin can't depend on things that Hudson supplies, since Maven is used in many other contexts (e.g., from the command line) where Hudson isn't available.

If your question actually is why the maven-release-plugin can't use a pure Java SVN client instead of relying on a command line client, then the answer is that it's because of a licensing issue (the SVNKit library can't be distributed under the ASF license). However, there is an implementation called maven-scm-provider-svnjava that you can use. I haven't tried it myself, so YMMV.

0
votes

The version of the Subversion for Windows client you are running locally is likely a higher version that your TortoiseSVN... Search Sourceforge for "Subversion for Windows" to find older versions.