[jira] [Closed] (SVN-4588) Item index too large in revision

["Nathan Hartman (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SVN-4588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nathan Hartman closed SVN-4588.
-------------------------------
    Resolution: Resolved

> 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)