On Wed, Feb 28, 2018 at 6:17 AM, Nico Kadel-Garcia <nkadel_at_gmail.com> wrote:
> On Tue, Feb 27, 2018 at 4:09 PM, Myria <myriachan_at_gmail.com> wrote:
>
>> Not to mention that the two revisions complained about are unrelated, and
>> 2/3 the repository history apart.
>>
>> One thing that's interesting is that the commit the svnsync failed on is a
>> gigantic commit. It's 1.8 GB. Maybe that svnsync is failing because of a
>> Subversion bug with huge files...?
>
> Hmm. Could 2 GB filesize limites be involved?
>
> When someone starts encountering this kind of issue with such large
> commits, it leads me to think "what the heck was in that commit"?
> There are various tools more likely to break when hammered that hard,
> wuch as pre-commit hooks written carelessly in Python that try to
> preload a hash with the contents of the file and just say "holy sone
> of a !@#$, I'm out of resources!!!". Been there, done that, had to
> explain the concept of reading a text file with a loop to the
> programmer in question.
>
The error with the 2 GB file occurred when trying to replicate the
repository in order to diagnose the original problem. The original
problem does not involve large files.
Also, I have no control over what was in the repository five years
ago. The huge files were compiled versions of WebKit libraries. The
alternative to committing these very large files would have been to
quadruple the build times, because it takes four times longer to build
WebKit than it does to build our project.
In other news, I can now reproduce the huge file problem in
TortoiseSVN committing to my "file:" partial copy of the repository.
However, with SourceForge down due to a DDoS, I cannot get the source
code to TortoiseSVN in order to debug it.
This does mean that this is very likely to be a Subversion bug,
probably something in 1.8.x or 1.9.x. The commit that prevented
"svnsync" from working was probably during 1.6 or 1.7, which
succeeded.
Melissa
Received on 2018-03-02 03:45:46 CET