subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johan Corveleyn <>
Subject Re: Vague error with subversion + apache22 + freebsd
Date Wed, 02 Jun 2010 22:53:14 GMT
On Wed, Jun 2, 2010 at 8:46 PM, Michael Zatopek <> wrote:
> Hi,
> I'm getting a vague error. I have subversion set up through apache on
> freebsd(all installed through ports). I'm working with a large repository
> containing lots of large files which I've migrated over from an older
> similar install on another machine using svnadmin dump/restore.
> I can navigate to the repository in firefox, see, and download files
> (including large binary files) without any problem. I can check out portions
> of the repository from the command line using http on the machine running
> the server (svn checkout without a problem.
> However, when doing a checkout onto any other remote system (windows or
> unix, using command line, or tortoisesvn), it grabs the first few folders
> but on hitting the first file(happens to be about 14mb) it gives this error:
> svn: REPORT of '/vault/!svn/vcc/default': 200 OK (
> On the server side I get the following errors from apache:
> [Wed Jun 02 13:43:10 2010] [info] [client X.X.X.X] (32)Broken pipe:
> core_output_filter: writing data to the network
> [Wed Jun 02 13:43:10 2010] [error] [client X.X.X.X] Provider encountered an
> error while streaming a REPORT response.  [500, #0]
> [Wed Jun 02 13:43:10 2010] [error] [client X.X.X.X] A failure occurred while
> driving the update report editor  [500, #53]
> [Wed Jun 02 13:43:10 2010] [error] [client X.X.X.X] Error writing base64
> data: Software caused connection abort  [500, #53]
> I'm running:
> svn, version 1.6.11 (r934486)
> Server version: Apache/2.2.15 (FreeBSD)
> I've dug around and seen people with similar messages, either related to
> problems not applicable to my setup or bugs fixed in earlier versions of
> subversion.
> Any ideas for things to try would be greatly appreciated.

Just a quick drive-by shot: take a look at networking components
between client and server (firewalls, proxies, ...). My prime suspect
would be a proxy (or proxy settings). Some proxies don't interoperate
well with svn (more particularly, some proxies have trouble with some
of the WebDAV methods that svn uses).

If there's no proxy and no firewall involved, I have no idea ...


View raw message