This bug has been resolved in Subversion Plugin 2.3. You just need to reconfigure your jobs. You have to add all SVN Credentials as "Additional Credentials" in the job config with correct realm notation "<proto://server:port> SvnRealmName". Please read the comments below.

It seems that the error only occurs on some of the svn:externals, but I can't find a pattern. A manual next build did not solve the issue for me.

There happened to be an issue before that is solved now.
It seems like the externals have not been taken intor account when fixing this.

I notice the same in our setup. After an upgrade, none of our jobs work correctly as we get "Authentication failures" randomly on one or more externals.
When reverting to 1.54, everything works fine again.
Very annoying that after a simple upgrade your complete installation does not work anymore ...

I see similar issue with some externals (not all) with following exception:

Feb 18, 2014 7:19:48 PM hudson.scm.SubversionRepositoryStatus$JobTriggerListenerImpl onNotify
WARNING: Failed to handle Subversion commit notification
org.tmatesoft.svn.core.SVNCancelException: svn: E200015: OPTIONS /svnroot/repo/path/to/external failed
        at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:384)
        at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373)
        at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361)
        at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707)
        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:1020)
        at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148)
        at hudson.scm.SubversionSCM$ModuleLocation.getUUID(SubversionSCM.java:2700)
        at hudson.scm.SubversionRepositoryStatus$JobTriggerListenerImpl.onNotify(SubversionRepositoryStatus.java:202)
        at hudson.scm.SubversionRepositoryStatus.doNotifyCommit(SubversionRepositoryStatus.java:136)
        at sun.reflect.GeneratedMethodAccessor348.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:616)
        at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:298)
        at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:161)
        at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:96)
        at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:120)
        at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
        at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:728)
        at org.kohsuke.stapler.Stapler.invoke(Stapler.java:858)
        at org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:390)
        at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:728)
        at org.kohsuke.stapler.Stapler.invoke(Stapler.java:858)
        at org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:390)
        at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:728)
        at org.kohsuke.stapler.Stapler.invoke(Stapler.java:858)
        at org.kohsuke.stapler.Stapler.invoke(Stapler.java:631)
        at org.kohsuke.stapler.Stapler.service(Stapler.java:225)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:45)
        at winstone.ServletConfiguration.execute(ServletConfiguration.java:248)
        at winstone.RequestDispatcher.forward(RequestDispatcher.java:333)
        at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:376)
        at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:96)
        at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:203)
        at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:181)
        at net.bull.javamelody.PluginMonitoringFilter.doFilter(PluginMonitoringFilter.java:86)
        at org.jvnet.hudson.plugins.monitoring.HudsonMonitoringFilter.doFilter(HudsonMonitoringFilter.java:90)
        at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:99)
        at hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:58)
        at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:99)
        at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:88)
        at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
        at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
        at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:48)
        at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
        at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
        at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84)
        at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51)
        at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
        at jenkins.security.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:117)
        at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
        at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125)
        at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
        at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:135)
        at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
        at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271)
        at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
        at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:174)
        at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
        at jenkins.security.ApiTokenFilter.doFilter(ApiTokenFilter.java:79)
        at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
        at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249)
        at hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:67)
        at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
        at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76)
        at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164)
        at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
        at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
        at org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:46)
        at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
        at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
        at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81)
        at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
        at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
        at winstone.RequestDispatcher.forward(RequestDispatcher.java:331)
        at winstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:227)
        at winstone.RequestHandlerThread.run(RequestHandlerThread.java:150)
        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 winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
        at java.lang.Thread.run(Thread.java:679)
Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: No credential to try. Authentication failed
        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.getFirstAuthentication(DefaultSVNAuthenticationManager.java:185)
        at hudson.scm.FilterSVNAuthenticationManager.getFirstAuthentication(FilterSVNAuthenticationManager.java:35)
        at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:694)
        at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382)
        ... 84 more
Feb 18, 2014 7:19:48 PM hudson.scm.SubversionRepositoryStatus$JobTriggerListenerImpl onNotify
WARNING: No subversion jobs using repository: 9ab88d41-efc2-4aad-9281-006de71726b0

I've reviewed credentials and even forced the same credentialsId in all subversion jobs using groovy script but still the stack traces show up. It seems as if from error message the protocol+server+port is missing as it doesn't look like an url, could the exception print also the job or referent url that refers to that "external" to help debug ?

I've got the same error since we updated the Subversion-Plugin from 1.54 to 2.2.
I found a pattern in my case. This only happens with our repository trigger and only with jobs, which have a special svn:externals definition.
The svn:externals are defined absolute (not relative) and refer another repository on the same host. 'Add additional credentials' don't work in all experiments with any kind of name-permutation in the 'Realm' field.
Other jobs with svn:externals relative to their own repository works fine, even if i start the problem jobs manually.
As work around i add the regarding external-url to the 'Source Code Management' section in the job configuration page and set the the repository depth to 'empty' and the 'Local module directory' to 'dummy_xxx'.

I had enable the polling from master option on startup "-Dhudson.scm.SubversionSCM.pollFromMaster=true" and after disabling it and restarting server, rechecking the polling from the slave instead of master now all urls fail to check with same stack trace.

svn checkout doesn't seem to have a problem.

Tested with Jenkins LTS 1.532.2 and svn plugin 2.2

After some additional testing it seems that subversion plugin is relying on host svn client configuration looking into $HOME/.subversion for the credentials instead of of using the ones configured in Jenkins.

When I used a Windows slave that didn't had a svn client installed or removed .subversion on linux slaves or master the problem to check on all urls is shown in scm polling log.

Similar problem here (Jenkins LTS 1.532.2 and Subversion Plugin 2.2):
Project1 has svn:externals property "^/project2/trunk/directory directory".

Checking out svn+ssh://server/repo/project1/trunk@3895 at revision 3895
A         xxx.xxx
...
 U        .
Fetching 'svn+ssh://server/repo/project2/trunk/directory' at -1 into 'C:\slavedir\workspace\jobdir\f99eb302\directory'
A         directory\yyy.yyy
...
 U        directory
At revision 3895
At revision 3895
hudson.util.IOException2: revision check failed on svn+ssh://server/repo/project2/trunk/directory
	at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:189)
	at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:132)
	at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:738)
	at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:899)
	at hudson.model.AbstractProject.checkout(AbstractProject.java:1411)
	at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:652)
	at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:561)
	at hudson.model.Run.execute(Run.java:1665)
	at hudson.matrix.MatrixRun.run(MatrixRun.java:146)
	at hudson.model.ResourceController.execute(ResourceController.java:88)
	at hudson.model.Executor.run(Executor.java:246)
Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: No credential to try. Authentication failed
	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.getFirstAuthentication(DefaultSVNAuthenticationManager.java:185)
	at org.tmatesoft.svn.core.internal.io.svn.SVNSSHConnector.open(SVNSSHConnector.java:77)
	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:1252)
	at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.getLatestRevision(SVNRepositoryImpl.java:168)
	at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:118)
	at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:148)
	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:20)
	at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238)
	at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
	at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:967)
	at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:872)
	at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:177)
	... 11 more

Same issue here with Jenkins 1.552 and Subversion Plugin 2.2 using Windows7 slaves.
All of our jobs configured to access SVN repositories via the svn:externals property are failing due to authentication failures.
Externals set to paths within the same repository and with different repositories both fail.
Setting "Additional Credentials" makes no difference whatsoever.

Same problem, Jenkins 1.552, SVN plugin 2.2, on RH Linux and Windows 7/2003.

Checkout works fine, but polling and change log querying randomly fail. There is no difference whether a build was started manually or triggered.

All svn:externals reference the same repo (^). The failures happen at random places; one external is queried successfully now and then fails on the next run.

Some additional information.
There's definitely some randomness in the authentication failures, but I've spotted a case where it occurs very frequently - svn:externals set to point to a file in the same repository.

same problem
found this bug-entry too late, so I opened another: JENKINS-22078

seems additional credentials for this specific external (same credentials as for the root project with the realm being the url to the external repo) made it work, but I have no intention of doing this for all my 50 projects...
edit: This did not work at all, the test case i made for it did that (see workaround)

workaround that works for me at the moment:

• create new project that watches the changes in my library (the external that is in common for all and fails with the revision check, repository depth=empty)
• configure other project as triggered by this new one

this seems to make the revision check work properly

what I'm currently doing is setup a subversion specific domain with all svn hosts listed (using wildcards and independent of protocol) with a using a single credential account to access all svn repositories.

Then I get that credential ID from browser url which is something like "6c9118bf-622a-498d-b244-3c3382d73a39"

To apply that credential to all jobs matching a regular expression I use the following groovy script:

/*** BEGIN META {
  "name" : "scm_svn_credentials",
  "comment" : "Check/Fix subversion credentials in jobs",
  "parameters" : [ 'CREDENTIALS', 'JOBS_PAT' ],
  "core": "1.532.2",
  "authors" : [
    { name : "Jose Miguel Sa" }
  ]
} END META**/

import hudson.scm.*

/** set input values **/
//String CREDENTIALS = "6c9118bf-622a-498d-b244-3c3382d73a39";
//String JOBS_PAT = ".*";

/** bulk apply changes **/
def updateSvn(job, CREDENTIALS) {
    def locations = [];
    for (loc in job.scm.getLocations()) {
        if ( CREDENTIALS != "" ) loc = loc.withCredentialsId(CREDENTIALS);
        locations.add(loc);
    }
    job.setScm(new SubversionSCM(locations,
        job.scm.workspaceUpdater,
        job.scm.browser,
        job.scm.excludedRegions,
        job.scm.excludedUsers,
        job.scm.excludedRevprop,
        job.scm.excludedCommitMessages,
        job.scm.includedRegions,
        job.scm.ignoreDirPropChanges,
        job.scm.filterChangelog,
        job.scm.additionalCredentials));
}

def printSvnLoc(loc) {
    println "  Location: $loc.remote";
    println "    local: $loc.local";
    println "    credentialsId: $loc.credentialsId";
    println "    depthOption: $loc.depthOption";
    println "    ignoreExternalsOption: $loc.ignoreExternalsOption";
}

def instance = hudson.model.Hudson.getInstance();
def jobs = instance.items;
for (job in jobs.findAll{ it.name =~ /^${JOBS_PAT}$/ }) {
    if (job instanceof hudson.model.ExternalJob) continue;
    if (job.scm instanceof hudson.scm.SubversionSCM) {
        println "\n[ job: $job.name ]";

       // Comment the following line when ready to efectivelly apply changes
    /*
        updateSvn(job, CREDENTIALS);
    //*/

        // check current values
        for (loc in job.scm.getLocations()) {
            printSvnLoc(loc);
        }
        println "  workspaceUpdater: $job.scm.workspaceUpdater";
        println "  browser: $job.scm.browser";
        println "  excludedRegions: $job.scm.excludedRegions";
        println "  excludedUsers: $job.scm.excludedUsers";
        println "  excludedRevprop: $job.scm.excludedRevprop";
        println "  excludedCommitMessages: $job.scm.excludedCommitMessages";
        println "  includedRegions: $job.scm.includedRegions";
        println "  ignoreDirPropChanges: $job.scm.ignoreDirPropChanges";
        println "  filterChangelog: $job.scm.filterChangelog";
        println "  additionalCredentials: $job.scm.additionalCredentials";
    }
}

Which aplies correctly the same credential to all svn locations, but still the actual changelog checks are failing because instead of relying on svnkit implementation it is delegating those to svn client installed in the account running the scm polling process, in Jenkins if polling from master is set, or from slaves otherwise.

I think I fixed the case of exceptions during post-commit notifications (notifyCommit):

https://github.com/daniel-beck/subversion-plugin/tree/notify-commit-external-credentials
https://github.com/daniel-beck/subversion-plugin/commit/aabd40a550461b08296ff3e971c80915ba22d9e0
(not a PR because it's not nice enough; feel free to build on this)

Have never seen the specific exception stack trace from the original report, so I don't know whether that is also resolved (but I doubt it).

To be specific, this is the case I resolved with this change:

1. Set up an SVN repo, anywhere. Can be locally file://...; no auth required.
2. Add an external somewhere that required credentials for access (below I used a repo accessed via HTTPS)
3. Check out the first repo
4. Build once to get the 'WARNING: The following realms could not be authenticated'
5. Configure additional credential for the realm it complains about, build again
6. No warning this time, external gets checked out
7. Script console:

def p = Jenkins.instance.getItemByFullName('jobname')
p.scm.getProjectLocations(p).findAll { it.remote.startsWith('https://') }.each { println it.getUUID(p) }

Result

org.tmatesoft.svn.core.SVNCancelException: svn: E200015: OPTIONS /svn/... failed
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:384)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361)
at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707)
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:1020)
at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148)
at hudson.scm.SubversionSCM$ModuleLocation.getUUID(SubversionSCM.java:2707)
at (user script)
Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: No credential to try. Authentication failed
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.getFirstAuthentication(DefaultSVNAuthenticationManager.java:185)
at hudson.scm.FilterSVNAuthenticationManager.getFirstAuthentication(FilterSVNAuthenticationManager.java:35)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:694)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382)
... 89 more 

Same issue here on linux debian, svn:externals on a local directory inside the same project (../../client/application/class class) , and it fails randomly.

hudson.util.IOException2: revision check failed on http://****/client/application/class
	at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:189)
	at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:132)
	at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:738)
	at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:899)
	at hudson.model.AbstractProject.checkout(AbstractProject.java:1414)
	at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:671)
	at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:580)
	at hudson.model.Run.execute(Run.java:1676)
	at hudson.matrix.MatrixBuild.run(MatrixBuild.java:304)
	at hudson.model.ResourceController.execute(ResourceController.java:88)
	at hudson.model.Executor.run(Executor.java:231)
	at hudson.model.OneOffExecutor.run(OneOffExecutor.java:43)
Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: OPTIONS /*****/client/application/class failed
	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:384)
	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373)
	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361)
	at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707)
	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:1020)
	at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:180)
	at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:118)
	at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:148)
	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:20)
	at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238)
	at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
	at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:967)
	at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:872)
	at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:177)
	... 12 more
Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: No credential to try. Authentication failed
	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.getFirstAuthentication(DefaultSVNAuthenticationManager.java:185)
	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:694)
	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382)
	... 30 more
Finished: FAILURE

Jocelyn: That particular issue looks like you can resolve it by adding an "additional credentials" entry below the list of module locations with a valid credential.

For realm, enter e.g.

<https://server:443> Subversion Authentication

It's the protocol, host, and port of the SVN service. The realm name (Subversion Authentication in my example is what your web browser shows in the password dialog when trying to access that URL.

Thanks Daniel, so far it seems it works perfectly

Same here - after upgrade to plugin 2.2

Does anyone experiencing the problem "No credential to try. Authentication failed" not fall in either of the following categories:

• External requires "additional credential" to be specified even though it's in the same repo as one of the configured module locations (click here for configuration instructions)
• External does not pick up credentials in post-commit hook (click here for detailed description and patched plugin that should resolve the issue)

If so, please add a comment and be really specific about the circumstances the problem appears in, as well as what happens (full stack trace, Jenkins log, ...).

adding this to all the job config.xml files (copied from one job where I entered the realm and credentials through the config tab)

<additionalCredentials>
   <hudson.scm.SubversionSCM_-AdditionalCredentials>
     <realm>&lt;https://[ServerName]:8443&gt; VisualSVN Server</realm>
     <credentialsId>....</credentialsId>
   </hudson.scm.SubversionSCM_-AdditionalCredentials>
</additionalCredentials>

and restarting the server worked for me
thank you, Daniel

note: this equals entering

<https://[ServerName]:8443> VisualSVN Server

in each job configuration as realm, but was much easier to do

Daniel: I am still experiencing authentication failures even with the additional credentials set.
My setup has Jenkins 1.552 and Subversion Plugin 2.2 (All Windows7 master/slaves).
There are several jobs checking out repositories with SVN externals set. All fail randomly.
One of the simpler jobs checks out a working directory from a repository with the following structure:

RepoA
├── ProjectA
│      └── trunk
│            ├── FolderA
│            └── FolderB
└── ProjectB
       └── trunk
              ├── FolderA
              └── FolderB <--- SVN External (^/ProjectA/trunk/FolderB)

ProjectB/trunk is set to be checked out, and the authentication fails on the SVN external.
I have added "Additional Credentials" with the realm set for RepoA, but still get "No credential to try. Authentication failed" as in the following stack trace:

hudson.util.IOException2: revision check failed on http://xxxxx/svn/ProjectA/trunk/FolderB
	at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:189)
	at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:132)
	at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:738)
	at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:899)
	at hudson.model.AbstractProject.checkout(AbstractProject.java:1411)
	at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:652)
	at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:561)
	at hudson.model.Run.execute(Run.java:1665)
	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
	at hudson.model.ResourceController.execute(ResourceController.java:88)
	at hudson.model.Executor.run(Executor.java:246)
Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: OPTIONS /svn/xxxxx/svn/ProjectA/trunk/FolderB failed
	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:384)
	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373)
	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361)
	at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707)
	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:1020)
	at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:180)
	at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:118)
	at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:148)
	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:20)
	at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238)
	at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
	at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:967)
	at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:872)
	at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:177)
	... 11 more
Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: No credential to try. Authentication failed
	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.getFirstAuthentication(DefaultSVNAuthenticationManager.java:185)
	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:694)
	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382)
	... 29 more

@chikigai:
the mistake I at first made was to enter the complete url to the external subproject as realm.
you have to enter it like in the screenshot I attached:

make sure to include the pointy brackets and to enter the title the server responses when you access it through the web interface (as Daniel said in comment-196363)
Our server provides this dialog
so "VisualSVN Server" is what I entered after the host-url (which is the one under the white rectangle).

This works for us and as we have a repository structure very similar to yours hopefully also works for you.

Does anybody know how to find out what realm to enter if you're using the "svn://" protocol, not http?

Alternative ways to find out your auth realm:

Command line SVN:

svn --no-auth-cache --config-dir invalid info proto://host:port/path/to/repo will show the auth realm, possibly after asking you to accept the certificate temporarily.

$ svn --no-auth-cache --config-dir invalid info proto://host:port/path/to/repo
Authentication realm: <proto://host:port> VisualSVN Server
Password for 'danielbeck': 

(invalid is the name of the directory – --config-dir – to get SVN client config from; in this case, should be non-existing dir, resulting in ignoring existing preferences like saved credentials). The dir will likely be created, just delete it afterwards.

Check the server config

If you use svnserve to serve the repo, check the realm directive in the [general] section of /path/to/repo/conf/svnserve.conf.

Patch the Subversion plugin

Unfortunately, logging is lacking in the current version of the plugin. This patch adds logging of URL and realm to auth attempts (logger hudson.scm.CredentialsSVNAuthenticationProviderImpl, level FINE):
https://github.com/daniel-beck/subversion-plugin/commit/e210707cef0dd419af4c0e4f409f0a16ef942156

Ask your SVN admin

Seriously. They'll know. (If you're the admin, well, maybe you shouldn't be.)

@soukupmi
Thank you for the detailed description.
However, I have already entered the realm as you have explained.
As I have stated in my previous comments, the failures are very random.
The authentication succeeds on some occasions, and fails on others.
I've even had the authentication succeed on the external without any additional credentials on some occasions.
Therefore, I am quite doubtful that the failures I am facing have anything to do with additional credentials.

Chikigai: It's likely a specific set of circumstances you didn't determine yet.

• Does it affect only certain projects?
• Does it affect only builds executing on certain slaves?
• Does it affect only certain actions (checkout, SVN post-commit hook, polling, ...)
• Does it affect only builds using a clean (or pre-existing) workspace?
• Does it affect only projects without existing builds?
• ...

if there's any variation in stack traces with the exception, posting those would be useful as well.

For example, I didn't even notice this problem (affected were polling and post-commit hook; resolved by adding extra credentials and patching the plugin, respectively) at first, as manually started builds successfully checked out everything, including the external. It's just that no build was able to detect changes in the external location (+ tons of exceptions logged like this one).

@danielbeck
OK, here's some more info which hopefully would be of some use.
Let me explain with some additions to the repository structure I used previously:

RepoA
├── ProjectA
│      └── trunk
│            ├── FolderA
│            └── FolderB
│                    └── external.c
└── ProjectB
       └── trunk
              ├── FolderA
              │     └── internal.c
              └── FolderB <--- SVN External (^/ProjectA/trunk/FolderB)

I have two jobs where:
[Job A]
Checks out ProjectA/trunk and then triggers Job B. (I created this job since changes in "external.c" would not be picked and trigger Job B)

[Job B]
Checks out ProjectB/trunk and runs a build.
Contains an additional credential as discussed in earlier comments.

And now a list of build triggers I tried with results:
[Job A + Manual trigger]
Job A succeeds, Job B is triggered and succeeds.

[Job B + Manual trigger]
Job B succeeds.

[Change/Commit "internal.c" + post-commit hook trigger]
Job B succeeds.

[Change/Commit "external.c" + post-commit hook trigger]
Job A succeeds, Job B is triggered and fails with authentication failure on the SVN external.
This failure occurs every single time via a post-commit hook trigger when "external.c" is commited.
Stack trace is exactly the same as posted in comment-196434.

I've same problem after update to 1.554

And I have workaround for this bug.
I changed svn update option to
"Emulate clean checkout by first deleting unversioned/ignored files, then 'svn update'"

@Alexander: I tried that ("Emulate clean checkout by first deleting unversioned/ignored files, then 'svn update'") today after updating to 1.554 - did not work.
same response as usual:

Started on 13.03.2014 08:41:58
Received SCM poll call ...
ERROR: Failed to check repository revision for https://[server]:8443/svn/IAB2.5/trunk/Library
org.tmatesoft.svn.core.SVNCancelException: svn: E200015: OPTIONS /svn/IAB2.5/trunk/Library failed
	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:384)
	...
	at java.lang.Thread.run(Unknown Source)
Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: No credential to try. Authentication failed
	at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.cancel(SVNErrorManager.java:37)

with the additional realm:

Started on 13.03.2014 09:26:04
Received SCM poll call on  for GATS on 13.03.2014 09:26:04
https://[server]:8443/svn/IAB2.5/branches/...GATS is at revision 6.235
https://[server]:8443/svn/IAB2.5/trunk/Library is at revision 7.106
https://[server]:8443/svn/IAB2.5/Projekte/...GATS is at revision 6.935
Done. Took 0,49 sec
No changes

@chikigai: you said

I have two jobs where:
[Job A]
Checks out ProjectA/trunk and then triggers Job B. (I created this job since changes in "external.c" would not be picked and trigger Job B)

[Job B]
Checks out ProjectB/trunk and runs a build.
Contains an additional credential as discussed in earlier comments.

did you also try with entering the additional credentials for Job A, too?

@soukupmi
Yes, I tried with additional credentials for Job A and Job B still fails.
If it worked however, I would be wondering how the credentials for one job would affect another.

@~chikigai: Is the behavior independent of whether a workspace already exists, and independent of whether earlier builds exist? Please create new projects just with the SCM config if necessary. I'll try to take a look at this tomorrow or on the weekend if I know how to reliably reproduce the problem.

@danielbeck
I created a repository exactly as posted in comment-196534.
Also created fresh jobs for Job A & B which only perform a checkout. (Additional credentials added too)
Here's what happened:

[Change/Commit "external.c" + post-commit hook trigger]
First time: Job A succeeds, Job B is triggered and succeeds.
Second time and onwards: Job A succeeds, Job B is triggered and fails.

I then deleted the workspace for Job B and tried again.
Job B fails.

I then deleted previous build related data and the workspace for job B and tried again.
No problems first time and Job B fails from second time onwards.

I then deleted previous build related data for job B and tried again. (left the workspace untouched)
No problems first time and Job B fails from second time onwards.

So with the fresh jobs and repository I used, it looks like previous build data of Job B is the failing factor.

Our repository structure in the SVN looks like this:

IAB2.5
  +-- trunk
  |     +-- Library
  |           +-- FolderA
  |           |     +-- externalA.c
  |           +-- FolderB
  |           |     +-- externalB.c
  |           +-- externalC.c
  |
  +-- branches
  |     +-- ProjectA
  |     |     +-- FolderA
  |     |     |     +-- external1.c
  |    	|     +-- FolderB
  |    	|     |     +-- external2.c
  |    ...    +-- external3.c
  |
  +-- Projects
        +-- ProjectB       <--- Jenkins Job A - watched for svn changes
        |     +-- FolderA  <--- SVN External (^/trunk/Library)
        |     +-- FolderB  <--- SVN External (^/branches/ProjectA)
        |     +-- FolderC
        |           +-- internal.c
        |
        +-- ProjectB1      <--- Jenkins Job B - triggered by Job A
        |     +-- FolderA  <--- SVN External (^/trunk/Library)
        |     +-- FolderB  <--- SVN External (^/branches/ProjectA1)
        |     +-- FolderC
       ...          +-- internal.c

Job A in Jenkins triggers on all SVN changes in the root Project, e.g.

• externalA.c
• externalB.c
• external2.c
• external3.c
• internal.c

--> they all trigger the checkout and rebuild of our ProjectB.
So a change in your external.c should be able to trigger your Job B too, as there is a new revision number created for it on the commit.

Also our ProjectB1 gets built by Job B which is started by Job A after it has finished.
They all work well now (all Jobs with additional credentials set, though).

Anyway, instead of post-commit hook trigger or any other hook we use svn polling (check repository every 1/4 hour). Could this be the reason why our setup works?

Chikigai: I may have fixed your issue. Completely untested (don't have a suitable test environment right now):
Commit: https://github.com/daniel-beck/subversion-plugin/commit/bb33856de17663faf1a26eebe86ba00076053394
Branch: https://github.com/daniel-beck/subversion-plugin/tree/notify-commit-external-credentials

How to checkout and build:

git clone https://github.com/daniel-beck/subversion-plugin.git . ; git checkout notify-commit-external-credentials ; mvn -DskipTests=true

@danielbeck
Forgive me for my lack of knowledge (this is the first time I'm building a Jenkins Plugin), but I'm unable to test your fix.
Here's what I tried:

1. Clone subversion-plugin
2. Checkout notify-commit-external-credentials
3. Build using maven
4. Installed subversion.hpi created in the target directory

The plugin is based on version 1.45 (shown in the installed plugins page) and does not recognize the credential related job settings.
I will have to add the credential again using the older method, but surely this is not what's expected.
I'm assuming I got something wrong here, so can you possibly point me in the right direction?

@soukupmi

So a change in your external.c should be able to trigger your Job B too, as there is a new revision number created for it on the commit.

Yes, that's what I expect too.
However, I have had some cases where the build would not start.
(Bare in mind the repository structure and externals set are far more complex than the example I've used)
I'm planning to look into this again once this issue with credentials is sorted out.

Chikigai: Subversion plugin 1.45 is bundled with Jenkins from 1.514-1.553, so it looks like you're back to the version bundled with your Jenkins.

If you installed the plugin by first removing everything in the $JENKINS_HOME/plugins folder whose name starts with subversion, start over, but this time create (or keep) the empty file named subversion.jpi.pinned – it prevents override from bundled plugins. The safest way to install/update is by using the file upload in Manage Jenkins » Manage Plugins » Advanced (if you're on 1.512 or later).

If my assumption is wrong, explain in detail how you installed the plugin.

@danielbeck
Thank you very much for the pointer.
I was manually removing the plugin from the plugins folder including the pin.
This time, I left the pin following your instructions and the plugin installed fine.
(Can't use the plugin upload feature since I always get a "Failed to dynamically deploy this plugin" error)

Unfortunately, I got the exact same authentication failure from the second time onwards:
1. Deleted previous build related data for job B. (left the workspace untouched)
2. Change/Commit "external.c" + post-commit hook trigger
3. Jobs A & B both succeed
4. Change/Commit "external.c" + post-commit hook trigger
5. Job B fails (stack trace is the same as before)

However, while trying out some other things, I noticed something with the settings of Job B.
I had the hostname of the server set in the repository URL for the checkout, and the ip address set in the realm of the additional credentionals.
I set the hostname in the realm and Job B no longer failed.
Then I set the ip address for both the repository URL and realm. Job B did not fail.
So it looks like you have to specify the same host format (name or ip address) for both the repository URL and realm of additional credentials.
This does not really make sense to me, since the credential I selected is associated with a domain containing both hostname and ip address.
Bare in mind, deleting the previous build data results in a job success even if the host format is different.

One final note, I tried the above with both the patched version and unmodified version 2.2.
Job B succeeds as long as the host format for the repository URL and realm are the same.

@Daniel Beck

i just tried to build and install your changes, but they did not change anything for us.

We still get the following error:
hudson.util.IOException2: revision check failed on http://10.28.201.18/svn/xxx/Website/Config/trunk
at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:226)
at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:169)
at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:739)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:900)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1414)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:671)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:580)
at hudson.model.Run.execute(Run.java:1676)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:231)
Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: OPTIONS /svn/xxx/Website/Config/trunk failed
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:384)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361)
at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707)
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:1020)
at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:180)
at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:118)
at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:148)
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:20)
at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:967)
at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:872)
at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:214)
... 11 more
Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: No credential to try. Authentication failed
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.getFirstAuthentication(DefaultSVNAuthenticationManager.java:185)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:694)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382)
... 29 more

Our repository A is on our svn server.
On the build it checks out all externals (from different repositories, all with the same credentials on the same svn server)
It fails to fetch the changelog for an external which is in the same repository A as the main project.

The issue ONLY happens if there was a change in repository B.

I tried it without additional credentials. i tried it with additional credentials and the realm set with the ip (http://ip/)
i tried it with additional credentials and the realm set to the svn subpath (http://ip/svn/)

Chikigai:

So it looks like you have to specify the same host format (name or ip address) for both the repository URL and realm of additional credentials.

Yes. The realm appears to be created from the host/port the client connects to, not from something the server reports. Which makes sense considering reverse proxies etc.

This does not really make sense to me, since the credential I selected is associated with a domain containing both hostname and ip address.

The realm string you specify is used as the key in a map, and the realm string SVNKit builds is used for the lookup of the credential to use in said map. (At least that's how it works for my first patch which I still believe to use correct)

Bare in mind, deleting the previous build data results in a job success even if the host format is different.

I found out after I asked for it that this is quite obvious in the code.

One final note, I tried the above with both the patched version and unmodified version 2.2.

Thanks for letting me know, now I can revert the change.

It really appears to me that any failures with this particular exception are user error (wrong realm names).

Mike Penz:

i tried it with additional credentials and the realm set with the ip (http://ip/)
i tried it with additional credentials and the realm set to the svn subpath (http://ip/svn/)

If you mean that you specified "http://ip/" and "http://ip/svn/" as realm strings: I'm pretty sure these are never valid realm strings and none of the methods I described above to find out the realm string returned these. It appears that you're simply guessing.

If you know how to read some Java: This is how they're created in the client library; and what you enter must be the exact same string:

https://github.com/jenkinsci/svnkit/blob/1.7.6-jenkins-2/svnkit/src/main/java/org/tmatesoft/svn/core/internal/io/svn/sasl/SVNSaslAuthenticator.java#L336
https://github.com/jenkinsci/svnkit/blob/1.7.6-jenkins-2/svnkit/src/main/java/org/tmatesoft/svn/core/internal/io/svn/SVNPlainAuthenticator.java#L60
https://github.com/jenkinsci/svnkit/blob/1.7.6-jenkins-2/svnkit/src/main/java/org/tmatesoft/svn/core/internal/io/svn/SVNSSHConnector.java#L76

Another way to find out the realm string if you use SVN from the command line (if you're on Linux or OS X; something similar should works on Windows as well):

find ~/.subversion/auth/svn.simple/ -type f -exec cat {} + | grep -A 2 realmstring

This will print all realm strings for which password credentials are saved by your SVN client.

Under Windows you can use findstr

findstr "<" %appdata%\Subversion\auth\svn.simple\*

unfortunately findstr is way not as flexible as grep, so you cannot print the lines following realmstring but only the line that contains it. This is why I chose to look for the "<" instead.

I was able to work around the issue by adding "additional credentials" with realm "<https://server:443> VisualSVN Server" and the same credentials that is used for the module itself.

We are facing the same issue as soon as there is an update in the svn:external linked folder.
At that moment we don't face the issue in the checkout or update, but we face this issue in the log determination.

When there is no change in the svn:external linked folder, then there is no issue.

Although I thought I had everything fixed, it looks like I'm still facing issues with commit notifications.
I no longer get authentication errors with the actual checkout, but the commit notifications via hook scripts are randomly failing.
The log shows "Failed to handle Subversion commit notification" followed by the same authentication error details as posted before.
I've run out of ideas of where to look for possible causes.

I can confirm that commit notifications via hook scripts are randomly failing for svn:externals as reported by chikigai. Without svn:externals everything seems to work as expected. In my case svn:externals point to other repositories on the same server and and the access rights do not differ from the main repository. So using the same credentials for svn:externals should work.

FYI my earlier fix has become PR 70 and was merged today, so using a snapshot build should resolve commit hook and subversion tagging plugin related issues.

I am randomly getting exceptions for svn projects that include external references:

Re-running the job usually fixes the error.

I have specified the 'Additional credential' as is required. The failures occur on both Linux and Windows slaves.

I think the error cases I am experiencing are similar to some of those discussed in this thread. Please will someone summarise the issue status and tell me if there is any fix I can apply?