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.

thetaphi: It only happens when you change the folder itself (e.g. change its properties like svn:ignore), not any children. This is fairly rare, at least in my workflow.

danielbeck I think it is probably a pretty common work flow scenario. Especially in a CI env (project dedicated to a team feature branch that frequently refreshes from trunk). Anytime we dedicate projects to specific SVN branches, which we do for major features and all releases, this becomes an issue since those types of branches will refresh from trunk often. This is what worries me about the next few weeks when we branch for our next release. Our first build is going to be fine, but subsequent builds that refresh partially from trunk will undoubtedly fail. Not going to be a good time for me.

Roger that! Same situation here. :-/

Same situation here. Externals are massivly used in our software landscape.

Untested fix prepared (don't have a Subversion environment at home and am on vacation right now. Plus, I'm lazy):

https://github.com/jenkinsci/subversion-plugin/pull/93

There'll be a build with it soon:
https://jenkins.ci.cloudbees.com/job/plugins/job/subversion-plugin/398/

This was written against the 2.4.x branch, so should be compatible with your systems if you're on 2.4.x.

So if you'd like to be used as a guinea pig, feel free to install the snapshot created by the build above (select module "Jenkins Subversion Plug-in", there are the artifacts).

Ha, you are far from lazy danielbeck Appreciate the untested fix. I do have an environment ready and setup to test this kind of stuff, I just have never built a plugin or installed an unofficial plugin. If there was a nice and easy process for me to follow to build and install it, I'd gladly make some time today to do that. I'll see what I can Google.

Uh... download the HPI produced in the build linked to above and install on Manage Plugins » Advanced tab.

You are on vacation so I thought "soon" meant after you got back. I didn't assume you'd have something available that quickly and thought I'd have to build it myself as I've seen you suggest others do in the past in this ticket.

thetaphi: It only happens when you change the folder itself (e.g. change its properties like svn:ignore), not any children. This is fairly rare, at least in my workflow.

It is quite common with subversion branches. At Apache Lucene, we have trunk and a stable release branch. The above failed build was against the stable release branch. On every merge from trunk to the release branch, you change a property on the root folder (the branch), so it happens on every commit and related Jenkins build of this branch.

You can try this out by looking at http://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x as a "testcase". It fails to checkout/update this in 2.4.2.

Uh... download the HPI produced in the build linked to above and install on Manage Plugins » Advanced tab.

I am installing that at the moment at the Apache Lucene/Solr Build server, to see if it works with the "stable branch" containing many merge props. Will report back.

Looks good:

Updating http://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x at revision '2014-08-20T12:55:30.731 +0000'
U         lucene\suggest\src\java\org\apache\lucene\search\suggest\analyzing\FreeTextSuggester.java
 U        lucene\suggest
 U        lucene
 U        .
At revision 1619094
No emails were triggered.

This revision was definitely one with changed svn:mergeprops.

thetaphi: Could you show the 'changes' table for the build?

http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Windows/4167/changes

Looks good here too. Going to run a few more tests, but I just did a big refresh from trunk so there was definitely a property update and lots of other updates as well. No failure.

Table looks like I expected. Nice when something occasionally works like that. I'll update the PR.

I guess this can be considered resolved, and all users with this problem and on 2.4.x can

• update to the snapshot build with the fix: https://jenkins.ci.cloudbees.com/job/plugins/job/subversion-plugin/398/org.jenkins-ci.plugins$subversion/artifact/org.jenkins-ci.plugins/subversion/2.4.3-SNAPSHOT/subversion-2.4.3-SNAPSHOT.hpi
• build from my branch: https://github.com/daniel-beck/subversion-plugin/tree/JENKINS-23146-2.4.x or
• merge the fix into their own branch: https://github.com/jenkinsci/subversion-plugin/pull/93/files

I hope we can get an official 2.4.x build released. jglick came through for us last time. If not, I'm fully prepared to use your snapshot build in production for now. Thanks danielbeck for taking care of us while on vacation. Hopefully you can look away from the Jenkins Issues page for a bit and actually vacation.

Code changed in jenkins
User: Daniel Beck
Path:
src/main/java/hudson/scm/DirAwareSVNXMLLogHandler.java
http://jenkins-ci.org/commit/subversion-plugin/3df6c0b32db52e275ff6158b93e2022c0067625c
Log:
JENKINS-23146 Handle changes to folder checked out to '.'

2.4.3 released and on CloudBees update center: http://jenkins-updates.cloudbees.com/download/plugins/subversion/2.4.3/subversion.hpi

OSS update center lags behind but should be there within a day.

(Not sure if this can now be closed as fixed.)

Code changed in jenkins
User: Daniel Beck
Path:
src/main/java/hudson/scm/DirAwareSVNXMLLogHandler.java
http://jenkins-ci.org/commit/subversion-plugin/14e5ca455e3786790ad5cb68348012f5d93376f8
Log:
JENKINS-23146 Handle changes to folder checked out to '.'

(cherry picked from commit 3df6c0b32db52e275ff6158b93e2022c0067625c)

With the cherry-pick to master I consider this fixed.

To get the fix, download 2.4.3 or the next 2.5 or higher release, or build from master.

Thanks to Daniel Beck and all who worked on this!

Pawel: This has nothing to do with this issue report.

Doesn't it? Tracker says something different.
My issue is the same as mentioned in the JENKINS-22158, which is a duplicated of JENKINS-22199, where you asked to forward to this Jira Slightly complicated, but I hope tracker doesn't outsmart us.

I think JENKINS-22158 is two separate issues, one in the original report, one in the first comment, and the one in the comment is what Yoichi Nakayama was referring to for JENKINS-22199.

To clarify, this issue here only occurs during the actual changelog computation, which happens only after a build is started; and your polling log happens before that (and actually triggers a build).

Thanks for clarification. I'm going to reopen JENKINS-22158 than.