I had the same problem.
When i use the Jenkins Artifact Plugin to perform a release,
a SVN Tag is failling due to the lack of credentials.
it display the message
"You are using an old subversion jenkins plugin, please consider upgrading."
As i'm using Subversion plugin version 2.5 (the latest), i was confused.
Downgrading to Subversion plugin 2.4.5 correct the problem !

Here my comment on artifactory Jira : https://www.jfrog.com/jira/browse/HAP-471?focusedCommentId=33422&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-33422

Please note that i'm using a Jenkins server on Windows. (The nodes are in Linux and Windows)
Jenkins ver. 1.596
Artifactory plugin 2.2.5

Hi,
What type of authentication are you using to let Jenkins access the SVN repository?

Regards,

B Olsson

I'm using HTTP authentification. I use the Credential Plugin : 1.20
Regards,
Cédric

Here some code from Artifactory Plugin :

sap = getJenkinsScm().createAuthenticationProvider(build.getParent(), getLocation());
} catch (NoSuchMethodError e) {
//fallback for versions under 2.x of org.jenkins-ci.plugins:subversion
buildListener.getLogger().println(
"[RELEASE] You are using an old subversion jenkins plugin, please consider upgrading.");
sap = getJenkinsScm().getDescriptor().createAuthenticationProvider(build.getParent());
}

https://github.com/JFrogDev/jenkins-artifactory-plugin/blob/master/src/main/java/org/jfrog/hudson/release/scm/svn/SubversionManager.java

Did your API changed ? Tell me as i can report to Artifactory JIRA.

I meant what type of authentication you have set up for your SVN server, Windows credentials or perhaps basic (i.e. username/passwords managed in the subversion server).

Regards,
B Olsson

In Subversion we have authenticated domain user (SERVER\user)
Regards,
Enri

Sorry. I'm using username/password.

I have the same issue, i get svn: E200015: authentication cancelled error when i use 2.5 plugin with svn 1.8 version

Also having this issue. plugin 2.5 with svn 1.8. Downgrading to 2.4.5 fixed this. This issue seems to have cropped up when we enabled apache2 + mod_auth_ntlm_winbind + winbind to use NTLM on the subversion host server.

We just upgraded to latest LTS version and have same issue using the global password of the Credential plugin, can even see the option to reconfigure to use the global credentials. Also suffering from https://issues.jenkins-ci.org/browse/JENKINS-26734

Same problem on latest LTS version. Polling works fine, but manual "Tag build" fails. HTTP basic auth on https. Reverting the plugin got back the situation to normal.

Same issue on 1.586 with subversion 2.5 plugin. i am using username/password

I confirm the issues with 1.609 subversion 2.5 too.

We've had a similar issue: same error message, different stacktrace.
Strangely, the update would run fine, but calculating changelog would result in error svn: E200015: authentication cancelled

Upgrading working copy format to 1.7 or 1.8 fixed the problem for us.

Can you check your workspace svn working copy version?
(try http://stackoverflow.com/a/1364648/2563933)

Upgrade with

svn upgrade <workspace-path>

I can confirm this issue to with 1.609 and 1.617 and Subversion plugin 2.5 too. I try to check out into an empty workspace from an https URL via username/password credentials:

org.tmatesoft.svn.core.SVNCancelException: svn: E200015: authentication cancelled
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.cancel(SVNErrorManager.java:37)
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.cancel(SVNErrorManager.java:32)
at org.tmatesoft.svn.core.internal.wc.DefaultSVNAuthenticationManager.getNextAuthentication(DefaultSVNAuthenticationManager.java:215)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:685)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:371)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:359)
at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:710)
at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627)
at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102)
at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1032)
at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:175)
at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:118)
at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:184)
at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:45)
at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.checkout(SvnNgAbstractUpdate.java:756)
at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:26)
at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:11)
at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20)
at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21)
at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1259)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
at hudson.scm.subversion.CheckoutUpdater$1.perform(CheckoutUpdater.java:115)
at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:162)
at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:170)
at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:133)
at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:162)
at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:991)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:972)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:948)
at hudson.FilePath.act(FilePath.java:991)
at hudson.FilePath.act(FilePath.java:969)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:897)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:833)
at hudson.scm.SCM.checkout(SCM.java:485)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1282)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:610)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:532)
at hudson.model.Run.execute(Run.java:1744)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:374)
FATAL: null
java.lang.NullPointerException
at java.util.ArrayList.addAll(Unknown Source)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:897)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:833)
at hudson.scm.SCM.checkout(SCM.java:485)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1282)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:610)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:532)
at hudson.model.Run.execute(Run.java:1744)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:374)
Finished: FAILURE

Can anybody provide a "step by step" process to reproduce the bug? Thanks in advance.

• Subversion server is Apache/2.2.15 (Win32) DAV/2 SVN/1.6.6 mod_auth_sspi/1.0.4 mod_ssl/2.2.15 OpenSSL/0.9.8m, NTLM authentication is used
• Use Jenkins 1.691 and update the Subversion plugin to 2.5
• Create a new item as freestyle project
• As source code management select Subversion
• As repository URL enter an repository with https URL that requires authentication
• Now add and select the required credentials via add, use kind username with password
• Below the credentials field the error 'svn: E200015: authentication cancelled' should appear
• Also as a result of this a build can't check out the code which was working properly with the previous Subversion plugin

Thomas Ascher, thanks so much. I hope to reproduce the bug following these steps.

Thomas Ascher, I tried to reproduce the bug without successful. I've recorded a screencast (https://goo.gl/uZ5N4P) to show how I tested it.

I think we can improve the UX if the recently created credential is selected.

I have two SVN repositories. One is on a Linux system. One is a 32 bit Windows system. I only have this problem with the Windows repository, the Linux repo works well. The Tortoise SVN client can use both repositories.

I think that since one person above mentioned that they are running on 32 bit Windows, there may have been a strange interaction.

Yes, our Subversion repository is hosted on a Windows machine. I've also done a quick evaulation on my own machine with a recent VisualSVN Server version which is also a SVN implementation and authentication seems to be a non issue with it. Maybe the SVNKit version that comes with the plugin isn't compatible with our specific server version anymore. At least according to the SVNKit changelog some changes were made to the NTLM authentication.

Thomas Ascher, William Albenzi

Now I have more information to work on this bug thanks to your comments. I'm going to configure an environment very similar to yours in order to reproduce the bug.

Mine looks like:

Apache2.2.29 (Win32) DAV/2 mod_ssl/2.2.29 OpenSSL/1.0.1m mod_auth_sspi/1.0.4 SVN/1.8.10
Jenkins ver. 1.615 and Subversion plugin 2.5
We use SSPI local windows authentication

We had this issue on svn running in Apache 2.2 on rhel 6.6. So it's not a Windows specific problem.

William Albenzi, Thomas Ascher

Maybe your bug is resolved with this PR. Its issue is JENKINS-27084.

We hope to release a new version of Subversion Plugin coming soon. Your feedback would be very useful.

Making the specified modification to Jenkins.xml and each node's Jenkins-slave.xml resolved my problem. Thank you.

Adding -Dsvnkit.http.methods=Basic,NTLM,Negotiate,Digest to the jenkins.xml works for me too. Thanks for the effort.

Thomas Ascher, I'm happy for read this. Let me to close this bug as duplicate of JENKINS-27084

Hello William Albenzi, what is "Jenkins.xml"? config.xml? And Jenkins-slave.xml would be nodes/NODENAME/config.xml?