[ https://issues.apache.org/jira/browse/SVN-4814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julian Foad closed SVN-4814. ---------------------------- Resolution: Invalid Assignee: (was: Stefan Fuhrmann) Closing because this issue clone is spam. > CLONE - Item index too large in revision > ---------------------------------------- > > Key: SVN-4814 > URL: https://issues.apache.org/jira/browse/SVN-4814 > Project: Subversion > Issue Type: Bug > Components: unknown > Affects Versions: 1.9.x > Reporter: SpArkx > 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 (v7.6.3#76005)