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

Re: Vague error with subversion + apache22 + freebsd

From: Michael Zatopek <zatomic_at_dizzylabs.org>
Date: Fri, 4 Jun 2010 08:13:13 -0500

I've done my best to verify that there are no network related issues.
Does anybody else have the most recent subversion + apache22 +
Freebsd 8.0 running? I kinda feel like there's some sort of version
incompatibility happening.

Is there any way to get more detailed error logs out of subversion or
apache in this case? I've got apache's logging turned up all the way
and it only gives the 4 vague messages from my original description.

At what point should I move this over onto the dev mailing list?

Thanks again,
Michael

On Jun 3, 2010, at 8:16 AM, Michael Zatopek wrote:

>
> On Jun 2, 2010, at 5:53 PM, Johan Corveleyn wrote:
>
>> On Wed, Jun 2, 2010 at 8:46 PM, Michael Zatopek
>> <zatomic_at_dizzylabs.org> 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 http://my.host.name/vault) 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 (http://
>>> my.host.name)
>>>
>>> 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)
>>> FreeBSD 8.0-RELEASE
>>>
>>> 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 ...
>>
>> Cheers,
>> --
>> Johan
>
> There is a simple NAT/Firewall (no proxy) between my windows
> desktop and the subversion server, which never caused a problem
> before connecting to our previous server in the same location. The
> unix box I tested from and got the same error has nothing between
> it and the server (both on public IP addresses with nothing but an
> ethernet switch between them). With that said, I'll do a few
> minutes of poking around to make sure there's not something hiding
> in my network configuration. In the meantime any other drive-by
> shots are very welcome.
>
> Thanks,
>
> Michael
Received on 2010-06-04 15:13:44 CEST

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.