I was trying to get a copy of the whole FPC SVN, but at some point, I get the following error:

"Server sent unexpected return value (413 Request Entity Too Large) in response to REPORT request for '/svn/fpc/!svn/vcc/default'"

Does anyone have any idea why I get this "413 Request Entity Too Large" message from the server?

And the Wow! thing is this:

From what I so far downloaded, my side of the copy is:

4.95 GB (5,315,804,192 bytes)
634,779 files
115,577 folders

Wow!

What svn command line are you using?

Maybe you are trying to download everything, including all tags, all branches, all binary files, etc, etc.

Usually you only want to download either trunk or the latest fixes branch.

Felipe Monteiro de Carvalho wrote

What svn command line are you using?

I am using the latest stable TortoiseSVN (Windows).

Maybe you are trying to download everything, including all tags, all branches, all binary files, etc, etc.

Yes. I deliberately want to do that.

Usually you only want to download either trunk or the latest fixes branch.

True. But, I want to get a full backup.

listmember wrote

I am using the latest stable TortoiseSVN (Windows).

I mean what command are you using. Something like:

svn co blablabla

I mean what command are you using. Something like: svn co blablabla

Since this is a point-n-click GUI thing, there's no command line that I know of.

But the URL I am using is this:

http://svn.freepascal.org/svn/fpc

So, which action from right-click menu have you chosen? SVN Checkout?

----------
Aleksa Todorovic
Lead Programmer
Eipix, Game Develoopment Company
www.eipix.com

You should be using

http://svn.freepascal.org/svn/fpc/trunk

You were trying to download trunk and all possible branches.

Michael.

You were trying to download trunk and all possible branches.

Of course I am. That was and is my intention.

My problem isn't disk space. Problem seems to be on the side of the server --somehow.

It tells my side (client, i.e. TortoiseSVN) "413 Request Entity Too Large" at exactly the same point all the time every time.

Aleksa Todorovic wrote

So, which action from right-click menu have you chosen? SVN Checkout?

First 'SVN Checkout'; then --after each failure-- 'SVN Update'

And the error is quite clear: you're pushing too much data to the server.

Try cutting up in several smaller chunks:
Browse the server repository, and request only the branches that you need.

Michael.

And the error is quite clear: you're pushing too much data to the server.

I don't have 'write' access. Not have I done any alterations to copy I have so far managed to get.

What data could I be pushing to the server?

Try cutting up in several smaller chunks: Browse the server repository, and request only the branches that you need.

Though I am not clear why this may make a difference, I'll try updating 'trunk', 'tags' and 'branches' separately.

The state of your current copy of the repository; From this the server can determine what data it should send and what not. If there are too many files, this will amount to a big request, and that could cause such an error response.

I think that is a good idea.

Michael.

Hmmmm.. That makes sense but I am not sure (how) it applies in my case.

Reason: I get this error quite consistently.

I mean, even when I first issued 'SVN Checkout' when there was nothing on my side to worry about difs and what not.

Seeing that it downloaded something like 4 GByte of data and then (and, only then) stopped due to server error, it implies (to me at least) that there is something wrong on the server side.

Anyway, thanks to you pointing out likelihood of me affecting the server somehow, I did some googling and it seems this is not such an uncommon issue.

Apparently, it has to do with Apache settings. IOW,

"413 Request Entity Too Large" problem can be solved by moving SSLVerifyClient from the directory level up to the virtual host level as found in Apache bug 39154,

See: http://svn.haxx.se/users/archive-2008-01/0689.shtml

or

http://www.svnforum.org/2017/viewtopic.php?t=3159

and, for the actual Apache bug report and workaround:

https://issues.apache.org/bugzilla/show_bug.cgi?id=39154