I'm seeing the same issue in a Linux environment, but our svn server uses NTLM.

Hi,
Have you tried reordering the authentication schemes?
Add this to the startup options in jenkins.xml:

-Dsvnkit.http.methods=Basic,NTLM,Negotiate,Digest

This means that Basic authentication will be tried first.

/ Björn

Adding -Dsvnkit.http.methods=Basic,NTLM,Negotiate,Digest to jenkins.xml fixes the issue.

I'm glad I could help!

/ Björn

Resolving, as the proposed workaround fixes the issue.

Now I'm just wondering:
Why is there a line saying lib.svnkit.http.methods Digest,Basic,NTLM,Negotiate when I go to JENKINS_HOST/systemInfo
even though I've added the -Dsvnkit.http.methods=Basic,NTLM,Negotiate,Digest to jenkins.xml?

lib.svnkit.http.methods=Digest,Basic,NTLM,Negotiate
svnkit.http.methods=Basic,NTLM,Negotiate,Digest

The first part, lib. subtle difference, and I don't know what the difference is, actually. Maybe someone else has the answer?

/ Björn

Well, it doesn't seem to be a workaround in all cases. We have several slaves running and the workaround only worked on some of them.
The rest throw this exception:

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.getRepositoryUUID(DAVRepository.java:143)
	at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339)
	at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328)
	at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482)
	at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364)
	at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274)
	at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27)
	at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11)
	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 org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311)
	at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291)
	at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387)
	at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157)
	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:989)
	at hudson.FilePath.act(FilePath.java:967)
	at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:897)
	at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:833)
	at hudson.scm.SCM.checkout(SCM.java:484)
	at hudson.model.AbstractProject.checkout(AbstractProject.java:1270)
	at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:609)
	at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:531)
	at hudson.model.Run.execute(Run.java:1750)
	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
	at hudson.model.ResourceController.execute(ResourceController.java:89)
	at hudson.model.Executor.run(Executor.java:240)
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:484)
	at hudson.model.AbstractProject.checkout(AbstractProject.java:1270)
	at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:609)
	at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:531)
	at hudson.model.Run.execute(Run.java:1750)
	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
	at hudson.model.ResourceController.execute(ResourceController.java:89)
	at hudson.model.Executor.run(Executor.java:240)

I've reopened the issue because the workaround doesn't work in all cases.

I don't know why the above workaround only works on some slaves but by adding -Dsvnkit.http.methods=Basic,NTLM,Negotiate,Digest to jenkins-slave.xml on the rest of the slaves seems to work.
This is really annoying since we have a lot of slaves.
It would be a little easier if I could set the property from the Jenkins master but JENKINS-9911 prevents me from doing so.
I'm not exactly sure how this works but don't I risk Jenkins overwriting jenkins-slave.xml at some point if I add the property to jenkins-slave.xml manually?

Unassigning from me, as I cannot delve into the code myself.

Could we expect a better handling of the situation at least ?
(A fix of the NullPointer, that should never be thrown in production ?)

Calls to svnkit.http.methods are only made in "SubversionSCM.java" from what I can tell.

The editor made no notes as to why they would have changed a call like:

System.setProperty("svnkit.http.methods","Digest,Basic,NTLM,Negotiate"); // as it was in 2.4.5

to

System.setProperty("lib.svnkit.http.methods","Digest,Basic,NTLM,Negotiate");// as it is now in 2.5

Maybe someone can find the reason in the check-in that changed the file.

Changing all calls to "lib.svnkit.http.methods" back to "svnkit.http.methods" in this file and recompiling the* .hpi *image seems to allow me to check out my repositories without issues.

I'm having this problem in Jenkins 1.614 on Ubuntu 14.04 LTS Server.

On Ubuntu server - there does not appear to be any jenkins.xml - I have config.xml in /usr/lib/jenkins, but since there is not tree/element information about where to put the configuration string, I can't see how to update the configurations to make this work.

I've found a couple of other bugs and discussions pointing to JAVA_ARGS and JENKINS_ARGS in /etc/default/jenkins - and have added the parameter as above, but it still is not working.

willste Interesting. https://github.com/jenkinsci/subversion-plugin/commit/966d051476cfbe880c6a820570ab370b3ec6da4d#commitcomment-11542216

Code changed in jenkins
User: christ66
Path:
src/main/java/hudson/scm/DirAwareSVNXMLLogHandler.java
src/main/java/hudson/scm/SubversionChangeLogBuilder.java
src/main/java/hudson/scm/SubversionEventHandlerImpl.java
src/main/java/hudson/scm/SubversionSCM.java
src/main/java/hudson/scm/UserProvidedCredential.java
src/main/java/hudson/scm/subversion/UpdateUpdater.java
src/test/java/hudson/scm/SubversionSCMTest.java
http://jenkins-ci.org/commit/subversion-plugin/2e6f2940b5f561b2377a72ddbe1fd9d7c0f15b52
Log:
JENKINS-27084 Revert system property changes.

Code changed in jenkins
User: Steven Christou
Path:
src/main/java/hudson/scm/DirAwareSVNXMLLogHandler.java
src/main/java/hudson/scm/SubversionChangeLogBuilder.java
src/main/java/hudson/scm/SubversionEventHandlerImpl.java
src/main/java/hudson/scm/SubversionSCM.java
src/main/java/hudson/scm/UserProvidedCredential.java
src/main/java/hudson/scm/subversion/UpdateUpdater.java
src/test/java/hudson/scm/SubversionSCMTest.java
http://jenkins-ci.org/commit/subversion-plugin/ad260ce0084b1e9fef9eae6ac14653bd1f5bcd74
Log:
Merge pull request #117 from christ66/JENKINS-27084

[FIXED JENKINS-27084] Revert system property change

Compare: https://github.com/jenkinsci/subversion-plugin/compare/a67ae6efb352...ad260ce0084b

Hi,

This bug is marked as delivered in the changelog for version 2.5.1 of the svn plugin: https://wiki.jenkins-ci.org/display/JENKINS/Subversion+Plugin

Can anyone confirm that this does indeed fix the issue for them - because I've tried installing Jenkins 1.623 with Subversion plugin 2.5.1 on a clean environment and I hit exactly this issue when I checkout externals (Windows master and Windows/Linux slaves). Either the fix is not actually contained within the plugin as listed, or I have encountered a different but visually similar problem.

I'm not currently blocked because I've reverted to the default svn plugin for now (1.5.4) and this functions perfectly in every way except for svn 1.8 support.

I am also still having an issue with svn: E200015: authentication cancelled error. RedHat Linux, Using Jenkins 1.624, Subversion plug-in 2.5.1, Subversion Client 1.8 with plain text passwords.

Steps I have taken:
changed svnkit.http.methods to Basic,NTLM,Negotiate,Digest
deleted my .subversion directory

Still having issues, see previous comments.

I'm also still having this issue, sadly.

nyoung02 I'd like to help in order to solve this bug.

1. Environment: Jenkins 1.623 + Subversion Plugin 2.5.1 running on Windows. (It seems it is happening on RedHat)
2. Add a FreeStyle Job
3. Configure a Subversion repository (auth required)
4. etc...

Please, Could you help me to complete this step by step process?

/cc ursus_b, mushadow

I tried to reproduce the error on a simple SVN configuration and repository, but I cannot reproduce for this simple case. The repository that fails on is a different svn server configuration with a more complicated repository structure. I will try to get a copy of the svn server configuration to try and reproduce the bug, if that doesn't work I will introduce some of the complexities such as externals and symbolic links to the repository. This may be one of those edge cases that are hard to narrow down.

mushadow This would be great! I want to know if your bug is related with this ticket or not. Thanks a lot for your time.

Found out the problem. It is more of a missed dependency on my part, but the error message is still the same and doesn't point to my missed dependency.

1. Install Jenkins 1.624 with Subversion plugin 2.5.1 set to checkout version 1.8
2. Create svn repo1, with an external to repo2 with a different user name. (see attached script below for repo setup)
3. Create Freestyle Job, add svn server path to repo1 and only supply the repo1 credentials, uncheck ignore externals
4. Run job to produce svn: E200015: authentication cancelled

Checking out svn://localhost/tmp/svn_test/repo1/project at revision '2015-08-20T10:16:44.101 -0500'
ERROR: Failed to check out svn://localhost/tmp/svn_test/repo1/project
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.svn.sasl.SVNSaslAuthenticator.createSaslClient(SVNSaslAuthenticator.java:310)
	at org.tmatesoft.svn.core.internal.io.svn.sasl.SVNSaslAuthenticator.authenticate(SVNSaslAuthenticator.java:140)
	at org.tmatesoft.svn.core.internal.io.svn.SVNConnection.authenticate(SVNConnection.java:198)
	at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.authenticate(SVNRepositoryImpl.java:1276)
	at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.openConnection(SVNRepositoryImpl.java:1254)
	at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.getLatestRevision(SVNRepositoryImpl.java:169)
	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.handleExternalItemChange(SvnNgAbstractUpdate.java:347)
	at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.handleExternalsChange(SvnNgAbstractUpdate.java:310)
	at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.handleExternals(SvnNgAbstractUpdate.java:246)
	at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.updateInternal(SvnNgAbstractUpdate.java:224)
	at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.update(SvnNgAbstractUpdate.java:72)
	at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.checkout(SvnNgAbstractUpdate.java:802)
	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.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$FileCallableWrapper.call(FilePath.java:2691)
	at hudson.remoting.UserRequest.perform(UserRequest.java:118)
	at hudson.remoting.UserRequest.perform(UserRequest.java:48)
	at hudson.remoting.Request$2.run(Request.java:287)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
	at java.util.concurrent.FutureTask.run(FutureTask.java:166)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at hudson.remoting.Engine$1$1.run(Engine.java:60)
	at java.lang.Thread.run(Thread.java:724)
AU        test.txt
 U        .
FATAL: null
java.lang.NullPointerException
	at java.util.ArrayList.addAll(ArrayList.java:530)
	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:1277)
	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:1741)
	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
	at hudson.model.ResourceController.execute(ResourceController.java:98)
	at hudson.model.Executor.run(Executor.java:381)
Started calculate disk usage of build
Finished Calculation of disk usage of build in 0 seconds
Started calculate disk usage of workspace
Finished Calculation of disk usage of workspace in 0 seconds
Finished: FAILURE

So the obvious problem is the missing credentials for the external. However when I switch the 2.5.1 plugin to checkout version 1.6, it doesn't fail (kind of question that it should fail); but it also gives me the nice output message that points to the problem. Our actual setup is much more complicated and was a repo for a different group with an external in an external. So it was three deep and I didn't know it was there, but the credentials were stored in my .subversion cache so it checkout fine on my box.

Cleaning local Directory .
Checking out svn://localhost/tmp/svn_test/repo1/project at revision '2015-08-20T10:17:40.280 -0500'
AU        test.txt
 U        .
At revision 2
WARNING: The following realms could not be authenticated:
 * <svn://localhost:3690> bc82e308-0615-4062-aeeb-e4222e8a1f7b
Adding missing realms to configuration...
Updated project configuration saved.
Started calculate disk usage of build
Finished Calculation of disk usage of build in 0 seconds
Started calculate disk usage of workspace
Finished Calculation of disk usage of workspace in 0 seconds
Finished: SUCCESS

SVN Repo setup code for RedHat

#!/bin/bash

#Created by Jeremy Eagan 08/20/2015
#Test case to setup svn repo for Jenkins Bug 27084
#Setup Instuctions
# 1.  Change the install location
# 2.  Beaware the script will turn on the svn server and kill it.
# 3.  Use at own risk, it should be safe but review for permissions and specific setup problems.
# 4.  Script will pause allowing you to run the Jenkins test, hit enter when Jenkins job is done to clean up the files.

installLocation="/tmp"
killsvn=false

pushd .

mkdir "${installLocation}/svn_test"
cd "${installLocation}/svn_test"
mkdir project
echo "Testing" > project/test.txt  #create some files to check in to repo

svnadmin create repo1
svnadmin create repo2

#configure svn repos
while read -r filename; do
  echo "[general]" > "$filename"
  echo "anon-access = none" >> "$filename"
  echo "auth-access = write" >> "$filename"
  echo "password-db = passwdnew" >> "$filename"
done < <(find -name "svnserve.conf")

#setup password files
while read -r filename; do
  echo "[users]"  > "$filename/passwdnew"
  userid=`echo $filename | sed 's/.*repo\([^/]*\).*/\1/'`
  echo "user${userid} = pa\$\$" >> "$filename/passwdnew"
done < <(find -name conf)


if [ "$(pgrep svnserve)" == "" ]; then 
    echo "Starting SVN Server"
    svnserve -d  #start svn server here if not started
    killsvn=true
fi

#add project to svn
svn import project "file:///${installLocation}/svn_test/repo1/project" -m"Initial file add"
svn import project "file:///${installLocation}/svn_test/repo2/project" -m"Initial file add"

#checkout projects
svn co "svn://localhost${installLocation}/svn_test/repo1/project" project1 --username user1 --password pa\$\$ --no-auth-cache

#add externals and check in changes
svn propset svn:externals "project2 svn://localhost${installLocation}/svn_test/repo2/project" project1
svn ci project1 -m"Adding project2 external to project1 repo" --username user1 --password pa\$\$ --no-auth-cache

echo "Add svn://localhost${installLocation}/svn_test/repo1/project to 
your Jenkins Freestyle job with username=user1 password=pa\$\$"

echo "SVN setup complete, ok to run jenkins test"
read input
rm "${installLocation}/svn_test" -rfv
if ${killsvn}; then
    pgrep "svnserve" | xargs kill
    echo "SVN Server Shutdown"
fi
popd

Just to add some more info, the svn repo was run on the Jenkins slave running the job so the external pointing to localhost was valid.

Using plugin 2.5.1 with subversion 1.8 checkout and proper credentials

Cleaning local Directory .
Checking out svn://localhost/tmp/svn_test/repo1/project at revision '2015-08-20T12:39:28.552 -0500'
AU        test.txt
 U        .
Fetching 'svn://localhost/tmp/svn_test/repo2/project' at -1 into '/local/jenkins/workspace/svn_test/project2'
AU        project2/test.txt
At revision 1
At revision 2
no change for svn://localhost/tmp/svn_test/repo1/project since the previous build
no change for svn://localhost/tmp/svn_test/repo2/project since the previous build
Started calculate disk usage of build
Finished Calculation of disk usage of build in 0 seconds
Started calculate disk usage of workspace
Finished Calculation of disk usage of workspace in 0 seconds
Finished: SUCCESS

mushadow I'm working on it. Trying to reproduce the bug.

We had the same issue after a Jenkins update and could solve it by reentering the password on the credentials page.

The password is stored in the credentials.xml file in Jenkins home directory. When I reentered the (same) password, the encrypted password hash apparently changed in the credentials.xml.
Maybe the password encryption method of the credentials plugin changed recently and the hashes are not properly migrated?

I hope this can help for someone else...

reentering the password did not work for me on Jenkins ver. 1.609.2 with plugin version 2.5.3

zesty, Please review these comments because there are users with the problem solved.

If you prefer, you can file a new ticket in which provide a step by step to reproduce the bug.

kamrup, If you agree, I'm going to close this ticket.

I think there are multiple issues all presenting with the same error message. I didn't see an update to the code so I'm assuming nothing has been done to clear up the issues. I think for the problem I was having, issuing an error message in 2.5.1 similar to the error message in 1.6 would point the user to the resolution. This would at least separate out a common mistake that presents as one of the multiple issues under the "svn: E200015: authentication cancelled" error message.

mushadow, It would be great if you file a new ticket with a step by step process to reproduce the bug.

IMO, don't make sense to have this kind of tickets opened without any advance.

I've upgraded to 2.5.3 and the issue seems to be fixed.

kamrup, thanks so much for your feedback. I'll close this ticket.

Hi ,

I am facing the same issue in jenkins 1.629 and subversion plugin 2.5.3 now.

I have read the above comments and found that upgrading the subversion from 2.5.1 to 2.5.3 fixed the issue.
can please you help me ?

I resolved the issue with subversion plugin 2.6 and setting -Dsvnkit.http.methods=Basic parameter in jenkins.xml file. The first time i included it at the end but the parameter didn't get picked up. You should place it before -jar like ".... -Dsvnkit.http.methods=Basic -jar "%BASE%\jenkins.war".
I used just basic as I don't need anything else. You will see in System information if it gets picked up after restarting jenkins. Check Manage Settings/System Info and search for "svnkit.http.methods".

Jenkins ver. 2.7.1 / Subversion 2.6

Setting the svnkit.http.methods property to Basic in both the master and the slave did not make a difference for me.

The source code of svnkit authentication looks like a maze of protocols, managers and special cases. So I followed someone else's work-around by setting the Jenkins project's SCM to None and using the Cygwin's svn command in the first build step to check out the code. I had to add "--username USER --password PASSWORD" in a one-off invocation of the job to get svn store the credentials in the Jenkins agent's home.

set svn_opts=--non-interactive --trust-server-cert-failures unknown-ca,cn-mismatch,expired
if exist .svn\nul ( 
    %cygbinslash%svn.exe update %svn_opts%
) else (
    %cygbinslash%svn.exe co %svn_opts% https://SERVER:PORT/svn/REPO/trunk/DIR .
)

Hello all,
I have the same issue with Jenkins 1.609.3 and SVN 2.5.7

The error is intermittent, it works 50% of the time and when it fails, I get the "org.tmatesoft.svn.core.SVNCancelException: svn: E200015: authentication cancelled". If I retry, it will sometimes pass and complete the build.

Caused by: 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.io.svn.SVNSSHConnector.open(SVNSSHConnector.java:149)
at org.tmatesoft.svn.core.internal.io.svn.SVNConnection.open(SVNConnection.java:77)
at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.openConnection(SVNRepositoryImpl.java:1273)
at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.getLatestRevision(SVNRepositoryImpl.java:172)
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.remote.SvnRemoteLog.run(SvnRemoteLog.java:160)
at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:35)
at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21)
at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1235)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:968)
at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:873)
at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:193)

I have a similar problem with the twist that util/lib is an http://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html directory under the same subversion server.
The platform is Linux Ubuntu 16.04.

No changes for svn+ssh://svn.example.com/util since the previous build
hudson.util.IOException2: revision check failed on svn+ssh://svn.example.com/util/lib
at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:208)
at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:138)
at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:725)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:860)
at hudson.scm.SCM.checkout(SCM.java:485)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1269)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:604)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
at hudson.model.Run.execute(Run.java:1741)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:410)
Caused by: 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.io.svn.SVNSSHConnector.open(SVNSSHConnector.java:149)
at org.tmatesoft.svn.core.internal.io.svn.SVNConnection.open(SVNConnection.java:77)
at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.openConnection(SVNRepositoryImpl.java:1273)
at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.getLatestRevision(SVNRepositoryImpl.java:172)
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.remote.SvnRemoteLog.run(SvnRemoteLog.java:160)
at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:35)
at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21)
at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1235)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:968)
at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:873)
at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:194)
... 12 more
Archiving artifacts

Hi Jens,

Try adding "additional credentials" in your job with the realm defined as svn+ssh://svn.example.com with credentials that fit with that server/repo.
Thanks,
Channy

Thank you! That worked but I don't understand why it worked? Didn't I just specify the same credentials again without the specific directory?
Doesn't it try to use the same credentials when resolving an External?
And previous versions didn't have this problem.

See JENKINS-21785. It's supposedly a security enhancement on forcing externals to be explicitly defined with their credentials. Not sure why only the changelog calculation is affected and not the actual checkout... It definitely does not use the same credentials as the Repository URL anymore when accessing externals.

I'm getting the:

org.tmatesoft.svn.core.SVNCancelException: svn: E200015: authentication cancelled

When trying to connect to an Assembla SVN repository via SSH. I am able to connect via HTTP with a username and password but not through SSH. I've tried all of the workarounds listed here with no success.

Assembla requires that an environment variable called REPO_NAME be set and forwarded for svn+ssh. The environment variable is set and the SendEnv is configured in ~/.ssh/config:

Host subversion.assembla.com
SendEnv REPO_NAME

It works via the command line as the Jenkins user. Will this be send through the subversion plugin in Jenkins?

For what it's worth, I was getting "svn: E200015: authentication cancelled" because my svn repo was using a self signed cert. I had to add that cert to java's cacerts keystore, using portecle on Windows, and then it worked fine.