subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chao.Guan" <mr_ker...@163.com>
Subject RE: An error occurred during decompression
Date Wed, 05 Nov 2014 02:23:49 GMT
> From: users-return-22456-mr_kernel=163.com@subversion.apache.org
> [mailto:users-return-22456-mr_kernel=163.com@subversion.apache.org] On
> Behalf Of Philip Martin
> Sent: Tuesday, November 04, 2014 7:27 PM
> To: Chao.Guan
> Cc: users@subversion.apache.org
> Subject: Re: An error occurred during decompression
> 
> "Chao.Guan" <mr_kernel@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*



Mime
View raw message