And does the path in question exist and accessible to you?

Given the way svn+ssh works, which is basically just "ssh jenkins@server svnserve repo", I find it rather unlikely that this breaks just because the server was upgraded.

Hi Kohsuke,

I've been having trouble with this myself and found out that this is an incompatibility bug with SVNKIT which affects other CI tools that rely on SVNKIT.

There will be a fix in SVNKIT 1.7 which is not 'preoduction ready' yet but might be useable for the purpose of this Subversion Plugin.
See: http://svnkit.com/download.php
Here is the explicit warning:

Subversion 1.7.0 Compatibility
Lastest stable version of SVNKit (1.3.6.1) is not compatible with Subversion 1.7.0 working copy format. However, SVNKit 1.7.0 is under development now and we plan to release it end of November 2011. Before that there will be a preview version available.
Right now you may use SVNKit 1.7.0-SNAPSHOT version, which is available in our maven repository or build SVNKit 1.7.0 from sources. SVNKit 1.7.0-SNAPSHOT is compatible both with the new and old working copy formats, but does not yer support all the Subversion operations.

This is the output I get when I try to specify a branch. Note that here the error is different from what Nikita is reporting since in that case it is an 'up' (update) command on an existing client. In my case Jenkins is new and the command is a 'co' (checkout), probably triggering different errors/exceptions in SVNKIT.

Started by user anonymous
Location 'svn+ssh://svn_host/repo/trunk' does not exist
Checking out a fresh workspace because there's no workspace at /home/jenkins/.jenkins/jobs/Build-trunk-client/workspace
Cleaning local Directory .
Checking out svn+ssh://svn_host/repo/trunk
ERROR: Failed to check out svn+ssh://svn_host/repo/trunk
org.tmatesoft.svn.core.SVNException: svn: URL 'svn+ssh://svn_host/repo/trunk' doesn't exist
	at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
	at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
	at org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:910)
	at hudson.scm.subversion.CheckoutUpdater$1.perform(CheckoutUpdater.java:84)
	at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:136)
	at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:144)
	at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:120)
	at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:136)
	at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:787)
	at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:768)
	at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:752)
	at hudson.FilePath.act(FilePath.java:783)
	at hudson.FilePath.act(FilePath.java:765)
	at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:742)
	at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:684)
	at hudson.model.AbstractProject.checkout(AbstractProject.java:1195)
	at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:568)
	at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:457)
	at hudson.model.Run.run(Run.java:1404)
	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
	at hudson.model.ResourceController.execute(ResourceController.java:88)
	at hudson.model.Executor.run(Executor.java:238)
Caused by: org.tmatesoft.svn.core.SVNErrorMessage: svn: URL 'svn+ssh://svn_host/repo/trunk' doesn't exist
	at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:163)
	at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:118)
	at org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:909)
	... 19 more
FATAL: null
java.lang.NullPointerException
	at java.util.ArrayList.addAll(ArrayList.java:497)
	at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:742)
	at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:684)
	at hudson.model.AbstractProject.checkout(AbstractProject.java:1195)
	at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:568)
	at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:457)
	at hudson.model.Run.run(Run.java:1404)
	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
	at hudson.model.ResourceController.execute(ResourceController.java:88)
	at hudson.model.Executor.run(Executor.java:238)

If I use 'svn+ssh://svn_host/repo/' then the Job will happily sync the entire repo including /trunk/, /branches/ and /tags/. This is obviously not an option as it would take hours to do a clean sync and we would probably run out of disk space.

I will see with our SVN admin if we can roll back to SVN 1.6 but that is probably not possible.

This caught me out too but I found really nasty work around:

Follow the instructions here to build SVNKit from trunk: http://svnkit.com/download.php i.e:

svn co http://svn.svnkit.com/repos/svnkit/trunk/
./gradlew clean build -x test

This should create a jar file called svnkit-1.7.0-SNAPSHOT_v20111203_1635.jar + sqljet-1.1.0-SNAPSHOT_r1158_v20110809_2108.jar, obviously depending on the precise revision when you do the checkout.

Copy both files into your $JENKINS/plugins/subversion/WEB-INF/lib directory.

Unzip both the existing and new SVNKit Jar files into temporary directories and then copy 'ISVNAuthenticationOutcomeListener.class' from the old unzipped SVNKit to the new SVNKit temporary directory at the same relative position. Rezip the new SVNKit from within the new temporary directory with 'zip -r ../svnkit-1.7.0-SNAPSHOT_v20111203_1635.jar .'

Delete the old SVN kit jar and any temporary files, move your new botched SVNKit jar into place and restart Jenkins. You should find you can now use svn+ssh against 1.7.1

Please disregard my previous comment. As you would imagine it has proven unstable and I would not recommend it.

What I'm doing for the moment is create a read-only git replica of the svn repo and have a Jenkins Job keep it in sync (1m lag). I did not import the entire history of the repo to save time (just last 2 weeks) as it will allow me to get up and running with Jenkins and showcase it as a good replacement for BuildBot. Once SVNKIT and the SVN Plugin are fixed switching back to svn for Jenkins should be trivial.

I do not recommend to do that to build your Prod builds if you plan on sticking with SVN, better roll back to SVN 1.6 if you can. For my purposes (continuous feedback on the submitted code) this will do for a few weeks. It will probably not scale on large repos (200k+) or repos with very large files due to git limitations.

An other options could be for you to stand up a SVN 1.6 read-only replica of your 1.7 master.

This issue is covered in SVNKIT-153, which is noted to be fixed in an upcoming 1.3.7 release. The svn-dev discussion referenced covers the details, but in summary, this issue affects any paths below the root due to how SVNKit used absolute paths instead of relative paths, and tightening up of the API in Subversion 1.7.x.

For me, I was able to downgrade to 1.6.x to work-around this issue for now.

Apparently 1.3.7 which was released on Dec 6 should work now:

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.

So, now that SVNKit 1.3.7 has fixed the path issue for svn 1.7 servers, should we be expecting a new version of the SVN plugin, which incorporates this fix? I am stuck with svn 1.7 servers, but would really like to use the svn plugin. Currently, it cannot check out the code because the URL is formed wrong.

As suggested on the mailing list, you should be able to expose your repository over http(s) and use that for Jenkins.

Thanks for the suggestion to use http protocol as a workaround for the svn protocol problem using SVNKit with svn 1.7 server.

Unfortunately, it does not work either. I am now hitting this error instead:
http://old.nabble.com/REPORT-request-failed-accessing-Sourceforge-Subversion-td14733189.html

So, I either have to fix the SVNKit issue with the http protocol, the issue with the svn protocol, or just not use svn 1.7 on my server. I need fixes in svn 1.7, so I don't want to abandon my effort to get this working.

Since I have no idea when a new version of Jenkins will come out that uses the new SVNKit (with fix), I would like to try using the current Jenkins and replacing SVNKit myself. Any advice on how to do this would be appreciated. (I also have to do the same thing for a Hudson installation, making it even less likely that I just want to wait for Jenkins/Hudson to come out with a version that includes the fixed SVNKit.)

Here my patches which up-port the changes in the svnkit-git-repository to 1.3.7.

The last patch may not be needed, for some reason i could not get the sqljet dependency otherwise.

I can provide this as git-repository as well if somebody is interested.

The resulting svnkit-library can then be included in the subversion-plugin to allow to access 1.7 subversion servers with the ssh+svn-protocol.

I will post the necessary changes to the subversion plugin in a minute...

Patch for subversion-plugin to build locally with the updated svnkit-library, I am not sure if any of these is actually needed or if these are just local problems that need to be worked around.

Can someone please update to SVNKIT 1.3.7? This is preventing us from upgrading our server to Subversion 1.7

my mistake

This is a duplicate of 11381 , right?
Oh, I guess that's a duplicate of this... /scratches head

This is preventing me from using Jenkins so the Blocker priority is right on!

I would just roll back to svn 1.6, but I have other services (python bindings involved...) that depend on 1.7. Fix it please. I'd be glad to fix it with a little help.

local build of the subversion plugin including svnkit-1.3.7 which allows to at least use Subversion 1.7 servers while the working copy is still pre-1.7 format.

Thanks very much!

To anyone interested, independent verification that this works. Allows jenkins to speak to a 1.7.x db, even though it checks out a 1.6-ish working copy for itself to use.

Basically, in my situation we all develop with 1.7.4 and check-in/merge/etc with that version, but for builds we let Jenkins manage it's own 1.6 working copy through this patched plugin.

Again, thanks VERY much centic, makes Jenkins useable again (for us anyway).

Experimental subversion plugin compiled with svnkit-1.7.4

Hi, I did a rough upgrade of the necessary pieces to build a subversion plugin which uses 1.7 working copy format.

Following github projects show the changes that I did, I also updated trilead-ssh2 which was upgraded in svnkit:

• https://github.com/centic9/trilead-ssh2
• https://github.com/centic9/svnkit
• https://github.com/centic9/subversion-plugin

As I am not the maintainer of these pieces, all this is AS IS, use at your own risk!

Also note that it will upgrade any existing working copy to 1.7 format without asking questions.

thanks centic, it is working.

I tried out subversion-svnkit-1.7.4.hpi.
It does recognize paths below trunk as svn repositories, from a 1.7 server.

Using the parametrized build to be able to select tags, it does not seem to list tags. Neither specifying the tags directory, nor the main repositors URL. In the first case, nothing shows. In the latter, only trunk shows.
I have not tried/used this priorily though, so don’t know if this is a new issue specific to 1.7 and/or this plugin (version).

ad problem with parameterized build:

• I investigated and reported the problem with parameterized builds to svnkit at http://issues.tmatesoft.com/issue/SVNKIT-248 as it turned out that it is a regression between svnkit 1.3.7 and svnkit 1.7.4. We may be able to work around it, though.

ad install:

• Just download the .hpi file, in Jenkins go to "Manage Jenkins -> Manage Plugins -> Advanced" and install the plugin-file via the file-input box.

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

Thanks centic for digging deeper into this. It sounds like a work around is to avoid using that particular overloaded form of the doList method so that we can pass in SVNDepth.IMMEDIATES?

Integrated in plugins_subversion #154
Added a test case for JENKINS-11933. (Revision 40560)
JENKINS-11933 tags and branches are now listed correctly with 1.7

This works around http://issues.tmatesoft.com/issue/SVNKIT-248 (Revision 40559)

Result = UNSTABLE
kohsuke :
Files :

• /trunk/hudson/plugins/subversion/src/test/java/hudson/scm/listtagsparameter/ListSubversionTagsParameterDefinitionTest.java
• /trunk/hudson/plugins/subversion/src/test/resources/hudson/scm/listtagsparameter
• /trunk/hudson/plugins/subversion/src/test/resources/hudson/scm/listtagsparameter/JENKINS-11933.zip

kohsuke :
Files :

• /trunk/hudson/plugins/subversion/src/main/java/hudson/scm/listtagsparameter/ListSubversionTagsParameterDefinition.java

Ad [1], yes, it looks like a regression that svnkit changed behavior for the doList() method that was used before, but the other form that is available allows to work around it nicely.

Released as 1.40.

it is not resolved

Code changed in jenkins
User: kohsuke
Path:
src/main/java/hudson/scm/listtagsparameter/ListSubversionTagsParameterDefinition.java
http://jenkins-ci.org/commit/subversion-plugin/09cd650c29df84461183e95c61f12954909f5648
Log:
JENKINS-11933 tags and branches are now listed correctly with 1.7

This works around http://issues.tmatesoft.com/issue/SVNKIT-248

Code changed in jenkins
User: kohsuke
Path:
src/test/java/hudson/scm/listtagsparameter/ListSubversionTagsParameterDefinitionTest.java
src/test/resources/hudson/scm/listtagsparameter/JENKINS-11933.zip
http://jenkins-ci.org/commit/subversion-plugin/ca5dadc3a52c2f098a5de23d06ee411fb469d6f2
Log:
Added a test case for JENKINS-11933.

Richard, given the nature of this problem, I suspect you are hitting a different issue. Please open a separate ticket with details.

Marking this issue as fixed again.

Marked it as fixed why don't ya. This things is not fixed. It just doesn't work.

When I logon to Jenkins server as Jenkins I can do svn ls svn+ssh://myuser@myhost/somerepos/somepathinrepos. No problem. When we add that url to jenkins it will fail with above message.

Support for Subversion isn't what it used to be. Maybe we need to switch to Git.

hmm, it seems to work for many people, and works for me also with svn+ssh, so I would suggest you create a new bug-entry together with information about which version of Jenkins and which version of Subversion Plugin you are using and also add some logfile of jenkins output, ...