subversion-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Julian Foad (JIRA)" <>
Subject [jira] [Deleted] (SVN-4814) CLONE - Item index too large in revision
Date Wed, 24 Apr 2019 16:20:00 GMT


Julian Foad deleted SVN-4814:

> CLONE - Item index too large in revision
> ----------------------------------------
>                 Key: SVN-4814
>                 URL:
>             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 ''
>     svn: Unexpected HTTP status 500 'Internal Server Error' on '/trunk/src/main/java/com/example/'
>     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:
> # 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
> # 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

View raw message