[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

svn checkout/update fails with svn: Decompression of svndiff data failed: size too large error

From: Rajesh Menakath <rajeshm_at_ivycomptech.com>
Date: Thu, 25 Nov 2010 13:31:52 +0530



  Recently we upgraded our svn server/client from 1.6.2 to 1.6.13, and
since then, we are encountering the following error when a user tries to
checkout/update a svn resource, where he has the required access (both
read and write).


    svn: REPORT of '/svnrepository/!svn/vcc/default': 200 OK
( <> ) -> this was with http
protocol, and found the below errors in apache error logs:


[Tue Nov 16 19:57:07 2010] [error] [client] Provider
encountered an error while streaming a REPORT response. [500, #0]

[Tue Nov 16 19:57:07 2010] [error] [client] A failure
occurred while driving the update report editor [500, #185005]

[Tue Nov 16 19:57:07 2010] [error] [client] Decompression of
svndiff data failed: size too large [500, #185005]


When I tried to do the same activity with svn protocol, I got the below


svn: Decompression of svndiff data failed: size too large


The weirdest part is that, it checks out the folder, but not the
contents of the folder, and then throws the error mentioned (for both
svn and http protocol).


When I tried to checkout all the files in the subjected folder, with the
help of svnlook (svnlook -r <last_modified_rev_on_that_folder> cat
repository_path file_path > testfile), I got the same error for one of
the file.

svnlook: Decompression of svndiff data failed: size too large


I could re-produce the error with both command line svn client, and
tortoise svn and in both windows (xp service pack 3), and linux (RHEL5)
environments. As mentioned earlier, both of our client and server are


Please confirm, if this is a bug or not, and suggest a way forward, and
let me know if you need any more info.


We could resolve the issue here for the time being, by deleting the
resource, and re-committing the same (luckily the user, who made the
last change, still had a working copy).


PS: posted the same at users mailing list, and confirmed that it's a
bug, possibly related to a known bug.







This email is sent for and on behalf of Ivy Comptech Private Limited. Ivy Comptech Private Limited is a limited liability company.

This email and any attachments are confidential, and may be legally privileged and protected by copyright. If you are not the intended recipient dissemination or copying of this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system.
Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract on behalf of Ivy Comptech Private Limited unless expressly indicated to the contrary and properly authorised. Any actions taken on the basis of this email are at the recipient's own risk.

Registered office:
Ivy Comptech Private Limited, Cyber Spazio, Road No. 2, Banjara Hills, Hyderabad 500 033, Andhra Pradesh, India. Registered number: 37994. Registered in India. A list of members' names is available for inspection at the registered office.
Received on 2010-11-25 09:11:09 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.