Does your virus scanner (local or on the server if G: is a network drive) do
something specific with that file? It appears that the tempfile that was just
created, disappeared before it could be moved into the pristine store.
Bert
Sent from Windows Mail
From: Stefan
Sent: Monday, Ja
Stuart MacDonald writes:
> svn: E175002: REPORT of '/svn/repos/deckard-65x/!svn/me': Could not read
> response body: connection was closed by server (http://foundry51.qnx.com)
I can provoke this on my local LAN by setting the Apache timeout on the
server to a low value such as 5 seconds. Then I
Here's this morning's failure. For testing, I've set http-timeout=67. I am
trying to see if the zero window is a coincidence or not.
The debug output:
Reading 8192 bytes of response body.
Got 8192 bytes.
XML: Parsing 8192 bytes.
XML: char-data (235) returns 0
XML: xmlParseChunk returned 0
Reading
I don't have access to the server log, but you can see from the wireshark
capture that the *client* closed the connection (look for the RST packet),
not the server. The error of "socket closed" is consistent with that.
I suspect that there's an issue handling the "http-timeout" timer; it gets
trig
Philip Martin writes:
> That message comes from ne_request.c and the -3 is NE_SOCK_CLOSED
> defined in ne_socket.h:
>
> #define NE_SOCK_CLOSED (-3)
> /* Connection was reset (e.g. server crashed) */
/* Socket was closed */
#define NE_SOCK_CLOSED (-3)
The comment associated with the constant is
stuartm.cod...@gmail.com writes:
> I have another failure, with some debug info, and some updates.
>
> We're switching to a different system for this particular repository, so I
> may or may not be able to continue debug efforts. :-(
>
> Since there's no debug info available for the svn 1.8 clien