I just found out that the file causing the error from the large commit
is not the large file - it's one of the smaller files, about 55 KB.
If I commit that single smaller file from the large commit, it errors
the same way as the original 227185 would. This is exactly like the
original problem with committing the pixel shader.
I managed to get the db/transactions/227184-4vb2.txn directory by
breakpointing kernel32!DeleteFileW in TortoiseSVN (so I could get the
contents before TortoiseSVN deleted them at failure). I don't know
how they're useful, though.
The only way I know how to proceed is to wait until the source code to
TortoiseSVN is available so that I can debug it in Visual Studio. Is
there something else I can do?
On Thu, Mar 1, 2018 at 6:45 PM, Myria <myriachan_at_gmail.com> wrote:
> 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 04:25:21 CET