Investigating.

Probably caused by my attempt in Subversion Plugin 2.4 to resolve JENKINS-18574. In my defense, the pull request had "request for comments" in the title and was merged anyway

Would help if you could provide the module locations in your job as well as the paths changed in SVN since the previous build. The former can be obtained by running this script in Jenkins Script Console:

def name = 'name of the job'

def p = Jenkins.instance.getItemByFullName(name)
def scm = p.scm
scm.getProjectLocations(p).each {
  println it.remote
  println it.local
}

What a mess. I suggest you downgrade to 2.3 for the time being. Alternatively, if you want the other 2.4 features, here's a patch:

https://github.com/daniel-beck/subversion-plugin/commit/03774c995cb53ff21a31a7bccfa79b66d087f3aa

Hi Daniel,

The output from the script in your earlier comment for one of the failed jobs is:

svn://svn/messagingPlatform/message-processing/trunk/application-messaging-platform-message-processing
.

In that particular job there were no scm changes.

Hi Kevin,

thanks for the info. If a build fails, it computes the changelog, and finds changed paths. Those are the interesting ones.

My current hypothesis (on which I base the first patch linked above) is that there are relevant change sets (commits) that contain paths both inside the path that is checked out (i.e. inside .../trunk/application-messaging-platform-message-processing in your case) and outside of it. So for analysis of your issue, I need both the checked out paths (which you provide) as well as the relevant change sets' changed paths.

Since it fails in changelog computation, and only compares current + previous build, at least every other build will succeed (as there'll be nothing to compare after a build failed during changelog computation!).

FYI, I use a build of 'big solution' plus PR 83 on my main instance for a week now (a few hundred mostly freestyle projects across multiple teams, maybe 100 or so builds every day), and have not experienced any problems.

Once I open a PR with the change, you could download a snapshot build. Any interest among the watchers in verifying the solution works?

I am not sure I can test this. I decided to stick with version 2.4 but I have not seen this problem since.

This seems odd as I did see the issue a number of times in the day or two after my last upgrade but not since.

If you're still looking for people to verify the solution. I'll volunteer.

mithander: Great! I opened a pull request with the fix:
https://github.com/jenkinsci/subversion-plugin/pull/85

Download a build for that PR from here (once finished):
https://jenkins.ci.cloudbees.com/job/plugins/job/subversion-plugin/369/org.jenkins-ci.plugins$subversion/

Should be the same as the version I've been using for two weeks now without problems except it doesn't contain PR 83.

I'm having this problem as well:

FATAL: String index out of range: -3
java.lang.StringIndexOutOfBoundsException: String index out of range: -3
	at java.lang.String.substring(String.java:1875)
	at hudson.scm.DirAwareSVNXMLLogHandler.sendToHandler(DirAwareSVNXMLLogHandler.java:111)
	at hudson.scm.DirAwareSVNXMLLogHandler.handleLogEntry(DirAwareSVNXMLLogHandler.java:82)
	at org.tmatesoft.svn.core.internal.wc2.compat.SvnCodec$7.receive(SvnCodec.java:167)
	at org.tmatesoft.svn.core.internal.wc2.compat.SvnCodec$7.receive(SvnCodec.java:164)
	at org.tmatesoft.svn.core.wc2.SvnReceivingOperation.receive(SvnReceivingOperation.java:78)
	at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.handleLogEntry(SvnRemoteLog.java:199)
	at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.logImpl(SVNRepositoryImpl.java:827)
	at org.tmatesoft.svn.core.io.SVNRepository.log(SVNRepository.java:1035)
	at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:181)
	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:179)
	at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:132)
	at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:735)
	at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:873)
	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:1684)
	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
	at hudson.model.ResourceController.execute(ResourceController.java:88)
	at hudson.model.Executor.run(Executor.java:231)

We also had this problem and switched to "2.5-SNAPSHOT (private-06/10/2014 23:14-jenkins)" of the Subversion-Plugin. The number of "index out of range" errors were significantly reduced but not completely eliminated.

Hi all,
I have also the same issue since I have upgraded subversion plugin from version 1.5 (or around it) to 2.4.
I don't specially need the features of 2.4 version compared to 2.3 version.
My question is, if I downgrade subversion plugin to 2.3,I fix this bug?

simabeis Please provide more specific information:

• What is that build based on (e.g. URL of its build somewhere)?
• What's the exact error and stack trace?
• What repository URLs did you check out in your project (e.g. https://svnserver/reponame/trunk/foo)?
• Which paths in the checked-out repos were changed between the previous build and the build that failed to compute the changelog (e.g. https://svnserver/reponame/trunk/foo/baz.txt and https://svnserver/reponame/trunk/bar/baz.txt)?

here is stack trace when issue appear:

hudson.util.IOException2: revision check failed on https://zao.secure.insidefr.com/svn/JAVA-DEV/PROJECT/Fluorine_Step3/trunk
at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:191)
at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:118)
at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:735)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:873)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1411)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:657)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:562)
at hudson.model.Run.execute(Run.java:1604)
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.SVNException: svn: E175002: REPORT /svn/JAVA-DEV/!svn/bc/6204/PROJECT/Fluorine_Step3/trunk failed
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:386)
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.doReport(DAVConnection.java:334)
at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:324)
at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.logImpl(DAVRepository.java:995)
at org.tmatesoft.svn.core.io.SVNRepository.log(SVNRepository.java:1035)
at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:181)
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:179)
... 11 more
Caused by: svn: E175002: REPORT /svn/JAVA-DEV/!svn/bc/6204/PROJECT/Fluorine_Step3/trunk failed
at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208)
at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154)
at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97)
... 27 more
Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: -2
at java.lang.String.substring(String.java:1937)
at java.lang.String.substring(String.java:1904)
at hudson.scm.DirAwareSVNXMLLogHandler.sendToHandler(DirAwareSVNXMLLogHandler.java:111)
at hudson.scm.DirAwareSVNXMLLogHandler.handleLogEntry(DirAwareSVNXMLLogHandler.java:82)
at org.tmatesoft.svn.core.internal.wc2.compat.SvnCodec$7.receive(SvnCodec.java:167)
at org.tmatesoft.svn.core.internal.wc2.compat.SvnCodec$7.receive(SvnCodec.java:164)
at org.tmatesoft.svn.core.wc2.SvnReceivingOperation.receive(SvnReceivingOperation.java:78)
at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.handleLogEntry(SvnRemoteLog.java:199)
at org.tmatesoft.svn.core.internal.io.dav.DAVRepository$1.handleLogEntry(DAVRepository.java:950)
at org.tmatesoft.svn.core.internal.io.dav.handlers.DAVLogHandler.endElement(DAVLogHandler.java:226)
at org.tmatesoft.svn.core.internal.io.dav.handlers.BasicDAVHandler.endElement(BasicDAVHandler.java:103)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:601)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1782)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2939)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:140)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:511)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:808)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.readData(HTTPConnection.java:911)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.readData(HTTPConnection.java:876)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.dispatch(HTTPRequest.java:220)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:480)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382)
... 26 more

the URL https://zao.secure.insidefr.com/svn/JAVA-DEV/PROJECT/Fluorine_Step3/trunk is used on around 10 builds on our jenkins server, and when issue appears, it appears on all build using this url.
An important point is that this SVN base have many externals.
I saw that errors appear only when change are made on external.

Florent: Version 2.4 is known to be broken (see the Subversion Plugin changelog in the wiki) and an at least partial fix already proposed; see earlier comments. I'd really like to know if Marcel Beister's build contains the proposed fix, and if so, what the circumstances for him are.

@Daniel: I will prepare the requested information in detail asap.

The problem occurred during (accidentally) switching the root node of the repository, e.g. from "https://server.com/svn-repo/Apps/AppA/trunk" to "https://server.com/svn-repo/Apps/AppA". There were no changes in the linked library that caused the "String index out of range" error.

I've tried using the "2.5-beta-3-SNAPSHOT (private-06/30/2014 16:31-jenkins)" version of the plugin to no avail. I'm still seeing the issue with the substr call for the supposed "added check." It's looking like the context is not being setup properly for each module or the url and repoUrl are incorrect. Anyway, here is the stack trace:

And the svn paths (yes, two seperate paths into two separate modules) that are being checked out with the alphabetic characters all swapped for A/a...

And the line of code that is failing...

EDIT: I'm also seeing the problem with single checkouts.

egsejenkins: I'm not surprised it doesn't work, as the proposed fix has not yet been merged into master, so you're running a version that is known to have the bug. If you're adventurous, create a snapshot build from this repo and branch and try again (you'll lose the changes of 2.5-beta-1/2 though, so in some respects it's a downgrade).

Hm, so there are no .hpi's sitting around with the fix on them? That's unfortunate... I'd rather not setup maven just to get this fix, but I guess that's what I'll have to do.

Well, I got adventurous and did as you suggested. I compiled and loaded in that branch of the plugin, and my tests are showing the issue to be resolved.

egsejenkins: Great, thanks for the feedback! I've removed the warning on the pull request and asked that it be merged. It'll probably be some time before a release is cut from that, thanks to the 2.5-beta nonsense.

Also, I should add that I needed the svnexternals fix from 2.4, so after realizing your branch was off of 2.3, I went ahead and merged your branch and the 2.4 tag. Then, I compiled and loaded my own custom version of the plugin with your fix and all of 2.4's features. Thus far, everything has been running great, and that's with hundreds of builds going through the system.

Alright, noticed one issue that still exists: If the folder you check out is changed (e.g. properties), results in StringIndexOutOfBoundsException. Will amend my PR.

I am not sure if this is relevant, but we see this issue with following environment:
master on windows and slaves on windows

mulrich: The only this relevant for this issue is the URLs checked out, and the URLs changed in the commits since the last build.

Ok, I see. If additional information or any testing is required, I volunteer.

Hi,

We also have the same issue. And we also need the svnexternals fix from 2.4...
egsejenkins : I am interested in your build. Could you please share your hpi with us ?

Unfortunately, my company's policy dictates that all developed code is proprietary, and I'm not sure whether merging other's code falls into this category. I'd rather err on the side of caution for my sake. Also, the merge was not too bad: simply download the 2.4 source and Beck's branch source, merge (keeping changes from both except on conflicts keeping Beck's), compile, and load the hpi through the updates manager.

egsejenkins : ok thanks I will try that. This bug is a real pain.

@Fabrice - We've been using the snapshot mentioned in this comment (if I remember correctly). Although it's a 2.3 snapshot, it's from after the svn:externals bug was fixed and before the StringIndexOutOfBoundsException bug was introduced. (I think. I admit I've had trouble keeping track of which bug is which and which versions are affected. It's been working well for us, at any rate.) That build has apparently expired from the Jenkins server, but I've put a copy on Dropbox in case it helps anyone.

jkelley Thanks Josh but I took the time (only 10 minutes) to merge Beck's branch into the 2.4.X branch and to generate the hpi.
So far so good, there have been no StringIndexOutOfBoundsException in our CI builds for 15 hours.

dionyweb: Just a heads up, the current fix attempt fails to compute the changelog when the folder being checked out is changed (e.g. its properties; original comment). I haven't had the time to fix this yet.

Hey guys, is https://github.com/jenkinsci/subversion-plugin/pull/85 still the correct/active fix for this?
What are my options to apply this fix to our production Jenkins install atm?
Do I need to merge that PR and compile my own subversion plugin?

Thanks

ttimo: That's the only solution I know of besides staying on 2.3. Note the limitation I mentioned both here and in the PR with changes to the checked out folder (e.g. properties).

I built my own Subversion plugin that includes that fix and one or two others. It's easy enough from within Jenkins as long as you have a JDK (and a Git binary) installed.

Sorry @Daniel I have only basic understanding of java build ecosystems.

• Am I am able to download the 2.3 subversion plugin from somewhere and just plop it into my 'latest' Jenkins installation (running 1.574 atm)?

• I was looking at https://jenkins.ci.cloudbees.com/job/plugins/job/subversion-plugin/, but it seems it's compiling all pull requests, and I'm not sure how to get just this one or to 'apply' it to my Jenkins installation. The compile for pull #85 has expired and is no longer available.

Any pointers would be greatly appreciated

http://updates.jenkins-ci.org/download/plugins/subversion/ or http://jenkins-updates.cloudbees.com/download/plugins/subversion/

danielbeck looks like we're seeing this now in version 2.4.1 of the plugin, and I should have expected it although in my testing of 2.4 and 2.4.1 on our sandbox I did not see this issue. I guess I was lucky. Any idea when this might be fixed? Could we get a 2.4.2?

FYI: PR 85 was merged into master, but thanks to the 2.5 beta changes (1.568+) it'll probably be some time until there's a release that is widely available, unless someone backports it to the 2.4.x line.
(Also, once again an unfinished PR was merged, just like the one that started this mess. At least this time it seems to be only incomplete fix rather than introducing regressions...)

------

To clarify the cause of this issue and how this could be tested (because this comment thread isn't long enough yet!):

• PR 85 fixes the situation when you change paths /foo/bar and /baz/qux in the repo in one commit, and check out /baz only.
• PR 85 does not fix when you check out /bar and that path is changed since the last build (e.g. property changes like svn:excludes).

In both cases, affected versions fail changelog computation and therefore the build. The next build will not break because of the same commit, so rebuilding may work.

As documented on the wiki, 2.4+ is affected, with the next 2.5-ish release probably no longer affected by the first list item above.

Thanks danielbeck. So who do we have to buy off to get the fix back-ported to 2.4.x? If 2.5 isn't coming out for a while, someone needs to fix such a significant bug in the 2.4.x line.

Also, would setting the "Retry Count" option to 2 or 3 (or higher) do any good in this instance? Here is the help text from that option for those that are unfamiliar "If a build fails to checkout from the repository, Jenkins will retry the specified number of times before giving up."

One of the Subversion plugin committers I guess. According to the wiki page there's a large selection to choose from. If one of you is a Cloudbees Jenkins Enterprise customer, file a support request with them.

Retry count wouldn't help. While I doubt that option applies to changelog computation, retrying the same broken string operations wouldn't do any good.

OK, I actually saw my issue happen at what appeared to be the "svn switch" (update), so I assumed that a retry might work for that. Maybe it just appears to be at that point but what is actually happening is the change log computation. I've added the retry already, so I'll just leave it. Can't hurt. Thanks. I really do hope they port this back and come out with a 2.4.2.

kerrhome I saw failures to switch before, but it's rare enough that I didn't want to investigate further. They didn't look like they were related to this either. If you can provide a reproducible test case, file a new issue.

Will do. Thanks. I only brought it up here because the error message here looks the same and we weren't getting it until I updated the SVN plugin to 2.4.1.

Just to confirm what Daniel already wrote, the Retry count is meaningless here. It only appeared to be that issue was happening during the update because it was so close, but the update went fine. The failure followed the update. I really wish this could be fixed in 2.4.2. Subversion plugin committers, will you please give us a patch for this?

I agree to Shannon and would appreciate a bug fix in 2.4.x.

Fix is merged to trunk, so why is this not Resolved/Fixed? Is there some outstanding case that remains unfixed?

Working on a backport.

Jesse: Fix is incomplete as mentioned in a comment to PR 85, here, here, and here.

Still getting failure after the plugin update. I assume it is for the case Daniel said is not fixed yet:

I had not executed a build for this branch in a while on this Jenkins sandbox and I know the branch has been refreshed from trunk (so merge info prop was added/modified).

danielbeck sorry to be a pest here. Any idea when the remaining issue you noted might be fixed? I'm wondering if I need to build my own hybrid of 2.3 + JENKINS-18534. We have a release coming up and I don't want management to run into this issue when building off our release branch. I've not built a Jenkins plugin before so it will be a challenge, but I don't want to rollback the time consuming changes I made when we moved to the 2.4.1 plugin to get JENKINS-18534.

Same issue here: After upgrading from 2.4.1 to 2.4.2 today, I get the following:

Building remotely on Windows VBOX (windows) in workspace C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows
Cleaning up C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\.
Updating http://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x at revision '2014-08-19T22:03:06.690 +0000'
UU        solr\CHANGES.txt
U         solr\core\src\java\org\apache\solr\handler\admin\SystemInfoHandler.java
U         solr\core\src\java\org\apache\solr\core\RunExecutableListener.java
 U        solr\core
U         solr\contrib\extraction\src\test\org\apache\solr\handler\extraction\ExtractingRequestHandlerTest.java
D         solr\contrib\extraction\src\test-files\extraction\enctypted-password-is-solrRules.pdf
A         solr\contrib\extraction\src\test-files\extraction\encrypted-password-is-solrRules.pdf
 U        solr\contrib
 U        solr
 U        .
At revision 1618997
hudson.util.IOException2: revision check failed on http://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x
	at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:191)
	at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:118)
	at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:735)
	at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:873)
	at hudson.model.AbstractProject.checkout(AbstractProject.java:1255)
	at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:624)
	at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:530)
	at hudson.model.Run.execute(Run.java:1740)
	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
	at hudson.model.ResourceController.execute(ResourceController.java:88)
	at hudson.model.Executor.run(Executor.java:233)
Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: REPORT /repos/asf/!svn/bc/1618960/lucene/dev/branches/branch_4x failed
	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:386)
	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.doReport(DAVConnection.java:334)
	at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:324)
	at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.logImpl(DAVRepository.java:995)
	at org.tmatesoft.svn.core.io.SVNRepository.log(SVNRepository.java:1035)
	at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:181)
	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:179)
	... 11 more
Caused by: svn: E175002: REPORT /repos/asf/!svn/bc/1618960/lucene/dev/branches/branch_4x failed
	at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208)
	at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154)
	at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97)
	... 27 more
Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: -1
	at java.lang.String.substring(String.java:1875)
	at hudson.scm.DirAwareSVNXMLLogHandler.sendToHandler(DirAwareSVNXMLLogHandler.java:121)
	at hudson.scm.DirAwareSVNXMLLogHandler.handleLogEntry(DirAwareSVNXMLLogHandler.java:83)
	at org.tmatesoft.svn.core.internal.wc2.compat.SvnCodec$7.receive(SvnCodec.java:167)
	at org.tmatesoft.svn.core.internal.wc2.compat.SvnCodec$7.receive(SvnCodec.java:164)
	at org.tmatesoft.svn.core.wc2.SvnReceivingOperation.receive(SvnReceivingOperation.java:78)
	at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.handleLogEntry(SvnRemoteLog.java:199)
	at org.tmatesoft.svn.core.internal.io.dav.DAVRepository$1.handleLogEntry(DAVRepository.java:950)
	at org.tmatesoft.svn.core.internal.io.dav.handlers.DAVLogHandler.endElement(DAVLogHandler.java:226)
	at org.tmatesoft.svn.core.internal.io.dav.handlers.BasicDAVHandler.endElement(BasicDAVHandler.java:103)
	at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:609)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1782)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2973)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:606)
	at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:117)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:510)
	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:848)
	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:777)
	at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
	at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1213)
	at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:648)
	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.readData(HTTPConnection.java:911)
	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.readData(HTTPConnection.java:876)
	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.dispatch(HTTPRequest.java:220)
	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:480)
	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382)
	... 26 more
Retrying after 10 seconds

This repeats several times. Very strange is that on such failed jobs I get "Tag this build" several times on the left navigation bar.

This is also a branch with many svn:mergeprops. The problem only happens on a branch, not on trunk.

I have now reverted to 2.4.1, will see if it works again.

Works fine with 2.4.1 after revert.

Responding to Jesse's question in IRC:

[00:46:36] <+jglick> danielbeck: JENKINS-23146 seems like your patch made the problem worse not better in 2.4.2?

I'm not sure what you're referring to, and the comments to the issue (kerrhome, thetaphi) all appear to be caused by the one known issue: PR 85 does not handle a change to the checked out folder if it's checked out as "." (which is why it's not marked resolved).

Responsible line is this, and the SIOOBE index is always -1: https://github.com/jenkinsci/subversion-plugin/pull/85/files#diff-f27623adeac6322c5230b6f7a5c91e7eR121

PR 85 does not handle a change to the checked out folder if it's checked out as "." (which is why it's not marked resolved).

In our case it is indeed checked out to ".". Are there any other configuration variant of checking something out directly to workspace folder, without subdir?

Nevertheless, it works in 2.4.1.