Hi Everyone,
I have (unfortunately) no java skills to assist with a solution.
But please let me add my +1 to the requirement to support SVN 1.7
We have recently upgraded SVN to 1.7
(It solves a few major issues we had with 1.6)

And subsequently cannot use Jenkins for checking out / updating our code.
We are able to do this via ANT, but it is slightly painful.

Gavin.

This is a critical bug. I just updated my subversion installation, and it broke Jenkins. I can't downgrade svn at this time.

Jenkins uses SVNKit internally for subversion support. Until SVNKit doesn't support 1.7 - announced for end of November http://svnkit.com/download.php - I'm afraid there isn't much we can do about it.

Thank you for the update kutzi.

BTW, I attempted simple jar substitution with trunk of svnkit, and that did not work. Bunch of missing class def exception.

Why not allow usage of the command line client, instead of just SVNKit? At least this way, you're not always dependent on a particular downstream product?

Implementing something like what tjuerge suggests in JENKINS-2296 (using svnClientAdapter) for the SVN plugin would get you 1.7 support using the command-line option. This is probably not a trivial fix though.

http://subclipse.tigris.org/source/browse/subclipse/trunk/svnClientAdapter/readme.txt?view=markup

Jenkins works fine with Subversion 1.7 if you use the HTTP protocol. The SVN protocol is broken due to a bug in SVNKIT: http://issues.tmatesoft.com/issue/SVNKIT-153

Note that SVNKit support for subversion 1.7 has two flavors. First, there is support for the 1.7 working copy format. This is not necessary to allow Jenkins to work with an svn 1.7 server.

The other problem is a bug with how SVNKit forms the URL when checking out code from an svn 1.7 server. THIS bug must be fixed before Jenkins can incorporate it.

I am happy to say that I checked SVNKit's site this morning, as I am as anxious as the rest of you. They have released 1.3.7, which claims to have fixed the URL bug. Now it is a matter of waiting until Jenkins has updated to the new SVNKit.

Here is the text from the SVNKit site:

Latest Stable Version
6 Dec 2011, 19:02, version 1.3.7
Changelog:
+ 1.7 Subversion servers compatibility issues fixed.
+ Export operation failed on missing directories, fixed.

• For new 1.7 Subversion working copy format support
  please use SVNKit 1.7.0-alpha version.

We are experiencing the same problem after an update to Subversion 1.7. Jenkins with over 120 projects all stands still for two weeks now.

Unfortunately switching to another protocol is not an option for us.

We are delaying the update of our SVN Server due to this Issue and for several other reasons we really would like to update...

>Why not allow usage of the command line client, instead of just SVNKit? At least this way, you're not always dependent on a particular downstream product?

I second this....

Is there some sort of ETA for this fix? I have quite a few projects that can no longer be built by Jenkins. I understand OS work is mostly done in people's spare time, but a rough estimate of when this can be fixed would be really appreciated.
Thanks a lot in advance.

>Why not allow usage of the command line client, instead of just SVNKit? At least this way, you're not always dependent on a particular downstream product?

I third this.

>Why not allow usage of the command line client, instead of just SVNKit? At least this way, you're not always dependent on a particular downstream product?

In that case you're dependent on having the user installed the 'right' version of the native svn client. I'm not sure if that is the better alternative.

> Is there some sort of ETA for this fix?

Jenkins SVN depends on SVNKIT. They have been promising a new version for a while, but always ran into trouble. Currently their web site says release Feb 2012, but since they are about to release beta, I am guessing March. It's a guess. I am sure Jenkins SVN people will update the plugin as soon as the underlying library is updated.

> In that case you're dependent on having the user installed the 'right' version of the native svn client. I'm not sure if that is the better alternative.

It worked fine for Netbeans for months... Jumping through some hoops is prefereable to it not working at all. I fourth this.

> In that case you're dependent on having the user installed the 'right' version of the native svn client. I'm not sure if that is the better alternative.

What about a global or a job configuration option to let the user decide which svn client to use?

Hi,

I've got a few projects which perform a svn commit as part of their build process (a script updates version numbers to match the build/revision before committing those changes back to the repository).

As a workaround, I've added an 'svn upgrade .' command before the 'svn commit .' statement. This means that the old-format working dir created by Jenkins is able to be committed at the end of the build.

This works, but almost doubles the time that each build takes. I'm really looking forward to an update to this plugin to support v1.7 working copies.

Of course, as mentioned, I'd also have no problem with an option to use the native svn client.

Thanks,
Chris

Any update on this? It appears that SVNKIT has updated their stuff? An ETA would be great.

I am not the maintainer, but interested in this...

SVNKit is still in release candidate stage, so I don't think svn plugin will be updated until SVNKit is fully released.

This is according to SVNKit's web page (http://svnkit.com/download.php):

"Lastest stable version of SVNKit (1.3.7) is not compatible with Subversion 1.7 working copy format. However, SVNKit 1.7 is under development now and we plan to release it in 12th of April 2012. We plan to publish first Release Candidate build till the end of February 2012."

This is in three days, when could we reasonably expect this to be rolled into the plugin if they do indeed release on the 12th?

SVNKit 1.7.4 has just been released. The download page says this:

Lastest stable version of SVNKit (1.7.4) is compatible with Subversion 1.7 working copy format and with Subversion 1.7 servers.

Due to released SVNKit, do you have any plans to update Subversion plugin?

Any updates on this? It appears there is a stable release of SVNKit which supports 1.7

There is my workaround :
1. Install the latest CollabNet Subversion Client to the server, which provides svn command-line tool.
2. Put all maven commands into a shell, i.e. bat for Windows.
3. Use maven-antrun-plugin to execute that shell.
4. In Jenkins configuration page, just use 'antrun:run' as the 'Goals and options'.

It works because the shell will use the system variable where PATH includes the latest CollabNet path rather than the old svn path used by Jenkins.

My website describes more : http://www.softhinker.com/in-the-news/howtomakejenkinssupportsubversion17

Your workaround seems good, but how you can replace Jenkins CI SVN checkout/update from SVN action? Current problem with SVN 1.7 support in Jenkins is: Jenkins will check-out/update project code from SVN 1.7 server in outdated SVN 1.6 file format and latest command-line SVN clients are not compatible with old SVN 1.6 file format

Not everyone uses ant/maven

I am agree with Jeremy, i.e. everyone wants to use the Jenkins with all its features "from the box" with the best performance. Does anyone knows how to speedUp this issue to be resolved?

I also want to point out, that the workaround is not applicable to all use cases of Jenkins and that this is a show stopper in some situations.
So as svnkit for svn 1.7 is availble now, this issue should be assigned as it is a "Blocker".

@Dmitry:
The only thing you can do to speed up the process is

• vote on this issue (left of top right)
• fix / implement it yourself and commit / provide patch/diff

Jan, I have considered trying to get the fix in myself. If I wasn't so busy right now I would. This is holding up a big integration we have done with our delivery process, so it's killing me, but not something I could do right away. I do like your suggestion of voting, more voices the better

Jay

Are there any plans going forward to decouple Jenkins from specific svn versions, i.e. allow the user to specify the executable? Like what is done for git etc...

SVNKit 1.7.4 is now out, which does allow functionality with both 1.7 server and working copies...

/hopeful glance?

Looks like Jenkins Jira is "dead"... really strange for a so popular service/product. Does anyone knows how to force this issue to be resolved (together with voiting)?

The hudson team did some work on this that included removing the customization to svn kit. If the same can be done with jenkins, you could just use the new svnkit library.

See http://issues.hudson-ci.org/browse/HUDSON-9111 for more info.

In JENKINS-11933, the 'duplicate' issue for this, someone added a patch file that theoretically upgrades the svnkit version from the defective 1.3.6.1 to the partially working 1.3.7 (this version can apparently speak to the 1.7.x server, though not 1.7.x working copy).

As I would guess that most of us are only using Jenkins to check out the latest version, this may serve as a workaround for many. However, applying a patch file is a little beyond my expertise. Is anyone able to see if that patch works, and if so, post the patched svnkit? It apparently makes a version called 1.3.7-jenkins-0.

All that being said, Dreyguy is right in saying the Hudson team made the right move. Decoupling the svnkit from the plugin would be desirable.

I have now attached the .hpi file that I use locally for getting at least 1.7-server supported in Jenkins to JENKINS-11933.

Thanks a lot!!! centic!!
It's working

@centric: Thanks for the patch. But it looks like even with your patch we still have a problem with full SVN 1.7 support by Jenkins.

I.e. currently on our build environments, Jenkins works fine with SVN 1.7 with old 1.6 SVN format. Everithing works correct, but.. performance of all SVN related operations is horrible. I.e. checkout of SVN 1.7 trunk by Jenkins with size about 100 MB takes about 30-40 minutes. Due to SVN 1.6 working format is used by current version of Jenkins SVN plugin, newest command-line SVN clients works with old SVN 1.6 format really slow. At the result our releases takes more then hour, where 40 minutes - it is a SVN-related tasks.
I am totally sure that update of Subversion plugin on Jenkins to latest SVNKit will fix all SVN performance re;lated problems.

Sorry, I already gave it a try and started the merge of 1.7.4 and the jenkins-specific changes, but there are a lot of conflicts and I lack some knowledge about the changes in the jenkins-version to tell me how to solve them... Maybe I try again and see if a hacky-wacky merge leads at least to a workable solution...

I tried replacing old current jars in /plugins/subversion/WEB-INF/lib/ with sequence-library-1.0.1.jar svnkit-1.7.4.jar, but getting following

FATAL: org/tmatesoft/svn/core/auth/ISVNAuthenticationOutcomeListener
java.lang.NoClassDefFoundError: org/tmatesoft/svn/core/auth/ISVNAuthenticationOutcomeListener

Please hold on for just a bit longer, I managed to merge the necessary pieces and started local testing yesterday, so far it looks promising.

I'll try to post an updated hack-build of the plugin and put all the necessary changes (svnkit/trilead-ssh2/subversion-plugin) on github so they can be reviewed and applied to the official sources easily. (I am not associated with any of these projects currently, so I cannot do offical builds here)

Please give the plugin available at JENKINS-11933 a try now, I did a minimal bit of local verification, so far it works for me.

Great job Centric! Thank you. I haven't tried your patches (because fo have no idea how to use them), but does anyone knows how this fix can be forced to be processed into the product?

This Jira is the most voted blocker in this project, why it is not assigned to anyone who have rights to include fixes in the product?

One Question:
Do i really have to wait for a working 1.7.4 SVN Plugin for JIRA ? If i use Jenkins against 1.7.4 SVN with 1.6 Plugin everything works fine except that the checked out workspaces are in the old 1.6 svn format. Are there any problems that i don't see ?

@Robert: Yes, it will work but really slow. Project workspace update/checkout and checkout from tag by old command-line svn clients (to support SVN 1.6 file format) will take a LOT of time. By example, our 100MB trunk svn checkout takes 40 minutes. So, update of svn pluging with new SVN file format support will increase perforamce of SVN related operations in 10 times!

@Dimitry
ok, just tried 60MB checkout on a Virtual Machine with Jenkins 1.461, SVN Plugin 1.34 and VisualSVN 2.5.4(the Version with SVN 1.7.4), it takes about 30seconds.
Nothing unusual so far...
Maybe the older 1.34 Version does not have this long checkout behaviour ?
...just tried with updated Plugin to 1.39, same result

FWIW, svnkit 1.7.4 hit maven central and should be generally available

Are we soon going to have a fix in the product for this issue ?
I cannot do maven releases because of this....

Hi,

We also are waiting for this update for 2 months, it should be great because of the SVN migration is postponed until the compatibility between our Jenkins platform and our new SVN plaform is made;

Good luke for the final lap of merging your work in the next release of Jenkins

Regards
Richard

Uploaded 1.40 RC that supports Subversion 1.7. I'm running this on http://ci.jenkins-ci.org/ now, but any additional beta testing appreciated.

It does pass all the tests we have, but there are major changes in SVNKit, so I'm being bit cautious.

I just tried the 1.40 RC, it throws an exception when attempting to check out to a directory that isn't a working copy (such as when "Always check out a fresh copy" is selected or if this is the first build):

ERROR: Failed to check out https://domain/svn/repo
org.tmatesoft.svn.core.SVNException: svn: E155007: 'C:\Data\Jenkins\workspace\job\src' is not a working copy
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
at org.tmatesoft.svn.core.internal.wc.admin.SVNAdminAreaFactory.open(SVNAdminAreaFactory.java:170)
at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.doOpen(SVNWCAccess.java:379)
at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.open(SVNWCAccess.java:283)
at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.open(SVNWCAccess.java:276)
at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.openAnchor(SVNWCAccess.java:171)
at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:514)
at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doCheckout(SVNUpdateClient16.java:965)
at org.tmatesoft.svn.core.internal.wc2.old.SvnOldCheckout.run(SvnOldCheckout.java:19)
at org.tmatesoft.svn.core.internal.wc2.old.SvnOldCheckout.run(SvnOldCheckout.java:8)
at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1221)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:292)
at org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:781)
at hudson.scm.subversion.CheckoutUpdater$1.perform(CheckoutUpdater.java:86)
at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:144)
at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:789)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:770)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:753)
at hudson.FilePath.act(FilePath.java:832)
at hudson.FilePath.act(FilePath.java:814)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:743)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:685)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1218)
at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:581)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:470)
at hudson.model.Run.run(Run.java:1434)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:239)
Caused by: svn: E155007: 'C:\Data\Jenkins\workspace\job\src' is not a working copy
at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:171)
at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:126)
at org.tmatesoft.svn.core.internal.wc.admin.SVNAdminAreaFactory.open(SVNAdminAreaFactory.java:165)
... 28 more
FATAL: null
java.lang.NullPointerException
at java.util.ArrayList.addAll(Unknown Source)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:743)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:685)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1218)
at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:581)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:470)
at hudson.model.Run.run(Run.java:1434)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:239)

Alexei, I couldn't reproduce the problem.

When this error happens, do you have C:\Data\Jenkins\workspace\job\src\.svn? I step executed the code and it does create the workspace right before the code gets to here.

The other experiment I'd like you to try is to use the scripting console, run "org.tmatesoft.svn.core.internal.wc.admin.SVNAdminAreaFactory.ourFactories;", and report back what you see. I wonder if someone else is setting that collection to empty, which would explain this.

I continue to look for other people trying out this version.

Out of curiosity, those experiencing long delays during any SVN operation when they upgraded their SVN plugin to use 1.7 format .. did you upgrade your working copy from 1.6 to 1.7 format first ?

http://subversion.apache.org/docs/release-notes/1.7.html#wc-ng

To quote:

"Upgrading the Working Copy

Subversion 1.7 introduces substantial changes to the working copy format. In previous releases of Subversion, Subversion would automatically update the working copy to the new format when a write operation was performed. Subversion 1.7, however, will make this a manual step. Before using Subversion 1.7 with their working copies, users will be required to run a new command, svn upgrade to update the metadata to the new format. This command may take a while, and for some users, it may be more practical to simply checkout a new working copy."