subversion-issues mailing list archives

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

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

Mime
View raw message