[
https://issues.apache.org/jira/browse/SVN-4814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Foad deleted SVN-4814:
-----------------------------
> CLONE - Item index too large in revision
> ----------------------------------------
>
> Key: SVN-4814
> URL: https://issues.apache.org/jira/browse/SVN-4814
> Project: Subversion
> Issue Type: Bug
> Reporter: SpArkx
> Priority: Blocker
>
> ***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
(v7.6.3#76005)
