Note that there are known issues in 1.576 that make it barely usable on some instances (JENKINS-24317). Make sure the issue occurs on 1.575.

It does exist on both. I was using 1.575 and was following the advice to not upgrade unless you see a bug.

Then, I upgraded to 1.576 and it still exists.

I've been able to work around it for now by installing the SVN Tag plugin; my best guess is it's an issue with not liking the url that's forced on us by VisualSVN http:/path-to-server/svn/yourreponame because I saw some behavior with it that appeared to think that http:/path-to-server/svn/ was the actual repo, whereas that's actually nothing; a web browser will list all of the available repos under that, but clients (command line, TortoiseSVN, SmartSVN) will throw an error.

I'm trying to figure out how to prove that out; I think what I can probably do is test using the tagger against the archives, which are NOT served by VisualSVN, and compare that behavior against the live ones which are served by it.

I'm seeing the same bug using Jenkins 1.588 with the Subversion Plug-in 2.4.4 on one of our servers. We have another server running the same versions but here tagging works. I can't figure out what the difference is between the two though - suggestions on what to look for?

It's hard to figure out what exactly is wrong since there's no error message.

Still present on Jenkins 1.590 with Subversion plugin 2.4.5.

After upgrading several other plugins I got the following exception when trying to tag:

Tagging http://HOSTNAME/svn/PATH/TO/REPO/trunk (rev.123321) to http://HOSTNAME/svn/PATH/TO/REPO/tags/NAME_OF_TAG
ERROR: Failed to tag
org.tmatesoft.svn.core.SVNCancelException: svn: E200015: OPTIONS /svn/PATH/TO/REPO/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.getRepositoryRoot(DAVRepository.java:132)
	at org.tmatesoft.svn.core.internal.wc.SVNCopyDriver.copyReposToRepos(SVNCopyDriver.java:194)
	at org.tmatesoft.svn.core.internal.wc.SVNCopyDriver.setupCopy(SVNCopyDriver.java:627)
	at org.tmatesoft.svn.core.internal.wc16.SVNCopyClient16.doCopy(SVNCopyClient16.java:440)
	at org.tmatesoft.svn.core.internal.wc2.remote.SvnNgReposToReposCopy.run(SvnNgReposToReposCopy.java:65)
	at org.tmatesoft.svn.core.internal.wc2.remote.SvnNgReposToReposCopy.run(SvnNgReposToReposCopy.java:23)
	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.wc2.SvnRemoteCopy.run(SvnRemoteCopy.java:227)
	at org.tmatesoft.svn.core.wc.SVNCopyClient.doCopy(SVNCopyClient.java:480)
	at hudson.scm.SubversionTagAction$TagWorkerThread.perform(SubversionTagAction.java:307)
	at hudson.model.TaskThread.run(TaskThread.java:127)
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)
	... 19 more
Completed

After changing the description of the credentials and running

svn --no-auth-cache --config-dir invalid info http://HOSTNAME/svn/PATH/TO/REPO/trunk

the exception disappeared and tagging fails silently again.

Realized that the svn authentication depending on the cached of the svn password stored in the user profile. What need to be done is in the OS, try to connect to the said repository and store the encrypted password when asked. You should find a new file created under User/.subversion/svn.simple with the said realm. After that your jenkins should be able to tag without any problem.

Another way is change the parameter name in the hudson.scm.SubversionTagAction from credentialsId to _.credentialId to enable the parameter value set by the user to be passed into the SVN authentication.

String credentialsId = parser.get("_.credentialsId");

Realized that the svn authentication depending on the cached of the svn password stored in the user profile. What need to be done is in the OS, try to connect to the said repository and store the encrypted password when asked. You should find a new file created under User/.subversion/svn.simple with the said realm. After that your jenkins should be able to tag without any problem.

This will override all authentication selected in Jenkins, leading to difficult to investigate problems when using multiple authentications each with only partial access to all Subversion repos used. So while a possible workaround in this case, it has severe, often undesirable side effects.

Realized that the svn authentication depending on the cached of the svn password stored in the user profile.

Does this mean that the username and password you choose for "Credentials for tagging" has no meaning?

I've just created a new issue https://issues.jenkins-ci.org/browse/JENKINS-26668, which I think describes what is actually going on. I believe "Tag this build" does not take any notice of the credentials set up in Jenkins. It just uses the credentials that the Subversion client has cached for you.

https://issues.jenkins-ci.org/browse/JENKINS-29225