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

RE: An error occurred during decompression

From: Chao.Guan <mr_kernel_at_163.com>
Date: Wed, 5 Nov 2014 10:23:49 +0800

> From: users-return-22456-mr_kernel=163.com_at_subversion.apache.org
> [mailto:users-return-22456-mr_kernel=163.com_at_subversion.apache.org] On
> Behalf Of Philip Martin
> Sent: Tuesday, November 04, 2014 7:27 PM
> To: Chao.Guan
> Cc: users_at_subversion.apache.org
> Subject: Re: An error occurred during decompression
>
> "Chao.Guan" <mr_kernel_at_163.com> writes:
>
> > I am using TortoiseSVN 1.8.7, Build 25475 - 64 Bit on my Win7. I
> > happened to see this information while updating contents: "ra_serf: An
> > error occurred during decompression".
> >
> > I have searched the source code of TortoiseSVN 1.8.7 but didn't find
> > any related code about it.
> >
> > I can't locate which commit cause the problem because there are about
> > 100 commit and each commit has 40-50M and plenty of files.
> > Can you guys give me some hints? What caused this error? What can I do
> > to fix it?
> >
> > By the way, one of my colleagues is using TortoiseSVN 1.7.11 on Win7,
> > he has this problem: "REPIRT of '/svn/st/!svn/vcc/default': Could not
> > read chunk
> > size: Secure connection truncated". Maybe those two error reports has
> > the same root cause. Also, I can't find the related source code.
> >
> > Guys, help me with that, please!
>
> http://svn.haxx.se/dev/archive-2014-10/0004.shtml
>
> There is a serf bug that causes an error on checkout/update bigger than
> 4GB:
>

This is weird, I get this error when I update a single folder of my working
copy. The whole working copy is about 40G, but the folder is only 814M, why
do I get the error then?

> svn: E120104: ra_serf: An error occurred during decompression
>
> This was fixed in serf 1.3.8. You may be able to work around this bug by
> disabling skelta mode on the client:
>
>
http://subversion.apache.org/docs/release-notes/1.8.html#serf-skelta-default
>
> You can also work around the bug by disabling HTTP compression on the
client
> or the server. However if the server is Apache 2.2 and you disable HTTP
> compression on the client while it remains enabled on the server you may
> trigger an Apache bug:
>
> 1.8 client:
> svn: E120106: ra_serf: The server sent a truncated HTTP response body.
>
> 1.7 client:
> svn: E175002: REPORT of '...': Could not read chunk size: connection was
> closed by server
>
> The Apache bug is a server crash so one user may see the error when some
> other user triggers the bug. The Apache bug is fixed in 2.4. You can
work
> around the Apache bug by disabling HTTP compression on the server.
>
> Note HTTP compression is distinct from the deltas that Subversion uses
> between client and server. Disabling HTTP compression does not stop
> Subversion clients sending/receiving deltas. Disabling HTTP compression
will
> mostly affect non-Subversion clients such as web browsers.
>
> --
> Philip Martin | Subversion Committer
> WANdisco // *Non-Stop Data*
Received on 2014-11-05 03:24:22 CET

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

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