So this seems to be a problem with svnrdump version 1.8.x?
Of course, we would prefer to use the latest svn 1.9.x version, but we find the CollabNet Subversion Edge package quite useful (apache2 and svn in one installer package; provides web-based management console).
Re: Error E140001: Sum of subblock sizes larger than total block content length
Ronald Taneza wrote on Tue, 21 Nov 2017 15:43 +0100:
> Checking the dump file produced by svnrdump (svn version 1.8.19), I noticed
> that the Content-length for the 2GB file is a negative value!
> The expected Content-length value is (prop-content length +
> text-content-length) = 2238208388.
> But the actual value is -2056758908, which is what you get when you try to
> interpret 2238208388 as a signed 32-bit integer (max 2147483647).
Subversion stores file sizes as svn_filesize_t which is an alias to
apr_int64_t which ought not to wrap until 2**63-1. Are apr_int64_t and
APR_INT64_T_FMT correct on your systems?
It's possible that we're casting 64bit->32bit somewhere --- that'd be a
bug --- but let's first rule out the above (heeding Occam's razor).
> *Sent:* dinsdag 21 november 2017 15:44
> *To:* [hidden email] >
> I got the error below while running "svnadmin load -M 0" to load a dump
> file created by "svnrdump dump".
> svnadmin: E140001: Sum of subblock sizes larger than total block
> content length
> This error was reported when "svnadmin load" was loading a big file
> (around 2 GB) from a revision in the dump file.
> Checking the dump file produced by svnrdump (svn version 1.8.19), I
> noticed that the Content-length for the 2GB file is a negative value!