[
https://issues.apache.org/jira/browse/SVN-4588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17023870#comment-17023870
]
Nathan Hartman commented on SVN-4588:
-------------------------------------
I'm closing this issue because it is not a bug. It was caused by replacing the
repository without restarting the server. This is *not* a supported use case;
the server must be stopped before changing the repository on disk and then
restarted afterwards.
There were discussions (see comments above, and references below), about
detecting this situation, e.g., by adding the instance ID to the cache key
prefix (and even other items, such as repo format, addressing mode, sharding
size). However, following those discussions, there is no way to handle this
reliably and it is better to "fail early" than to open a whole can of worms of
subtle race conditions that may arise.
The release notes for 1.8 and 1.9 were updated to reflect the server restart
requirement.
References:
See, "Issue #4588, part 1: FSFS access error" on dev@, 2015 Aug 23:
[https://lists.apache.org/thread.html/4ce6e08318abcd3d60f4d4a24f62fb621d0cda450206a8628b129260%401440358683%40%3Cdev.subversion.apache.org%3E]
and this later thread, "Bug review of the week" on dev@, 2020 Jan 08, archived
here:
[https://lists.apache.org/thread.html/r44a6370ab5fb211fad77f7aad49131763180db4e4c26c0f68df566d4%40%3Cdev.subversion.apache.org%3E]
If you believe this issue to be closed in error, please file a new one with a
proper description (i.e., a feature request to detect this admin error) and
reference this issue and the above discussions. Thanks.
> Item index too large in revision
> --------------------------------
>
> Key: SVN-4588
> URL: https://issues.apache.org/jira/browse/SVN-4588
> Project: Subversion
> Issue Type: Bug
> Components: unknown
> Affects Versions: 1.9.x
> Reporter: Subversion Importer
> Assignee: Stefan Fuhrmann
> Priority: Blocker
> Fix For: ---
>
> Attachments: 1_globalmentor-repo-1.8-java-db-revs-1-1925.7z,
> 2_globalmentor-repo-1.9-java-db-revs-1-1925.7z
>
>
> ***Short version:
> I installed Subversion 1.9 on my server, and my Subclipse client using JavaHL
> in Eclipse 4.5 suddenly got this error when I tried to look at the history of
> a file:
> {noformat}
> org.apache.subversion.javahl.ClientException: RA layer request failed
> svn: Unable to connect to a repository at URL
> 'https://svn.example.com/trunk/src/main/java/com/example/FooBar.java'
> svn: Unexpected HTTP status 500 'Internal Server Error' on
> '/trunk/src/main/java/com/example/FooBart.java'
>
> APR does not understand this error code
> svn: Additional errors:
> svn: Item index 5460 too large in revision 1925
> {noformat}
> I reinstalled Subversion 1.8, and this error went away.
> ***Long version
> # Subversion 1.9 is out. Yay! I decided to upgrade right away.
> # I tried to download and build the tarball, but now Subversion requires
> Python 2.7, which is quite hard to get on CentOS 6.4, because it conflicts
> with yum, etc. So I guess I'll skip running tests.
> # Alas Subversion 1.9 requires a higher version of Serf than I get with
> CentOS 6.4, so I decide to build it myself. It requires oodles of
> configuration using something called scons, and when I try to test the build,
> it fails. So I guess
> my brand new Subversion 1.9 won't have HTTP(S) support, either. But at least
> I'll have an extra-efficient repository on the server... right?
> # So Subversion 1.9 is now running on to the server. I go to my main
> repository (which I've been maintaining since around the time of the first
> public release of Subversion 1.0) and do a dump. Then I do a load. Oh...
> Subversion tells me
> that it won't do a reload because some of my super-old (decades-old?) svn:log
> entries don't have canonical EOLs (probably some old client put a few CRLFs
> in). (So svnadmin, why don't you fix it for me? Is it really so hard?)
> # Because I had (foolishly) deleted my original repository after dumping
> (what was I thinking?) I had to use the --bypass-prop-validation switch just
> to get a repository back. But how to get rid of all those bad EOLs? I came up
> with an elaborate dance using svnsync (because apparently it is smarter than
> svnadmin and can normalize EOLs). You can read the gory details here:
> http://stackoverflow.com/a/32030939/421049
> # Of course the new repository has the wrong UUID, so I had to use svnadmin
> setuuid to make my clients recognize it.
> # Then I tried to see the history of a file on my client, which is Subclipse
> on Eclipse 4.5 using JavaHL. (Subversion 1.8 clients can work with Subversion
> 1.9 servers, right?) That's when I get that long error I showed above.
> # Thinking that this stemmed from my elaborate dance using svnsync, I went to
> the server and switched back to the repository I had loaded using
> --bypass-prop-validation. Nope, same error.
> # Crossing my fingers, I downloaded the latest Subversion 1.8 series and
> installed it. I re-loaded the svnsync version of my repository (the one with
> normalized EOLs). Suddenly my Eclipse 4.5 with Subclipse and JavaHL are
> working again.
> Now that it's working I'm not touching anything until I get this all
> converted to Git. I must have been crazy to try to upgrade to Subversion 1.9
> so soon...
> Original issue reported by *garretwilson*
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
