svn更新/签出/提交失败

Question

environment:

client
windows 7 ultimate x64
TortoiseSVN(lastest)

server
ubuntu 10.4
svn (it installed by another one that is not me. they call it just 'svn'. i'm not expert on linux system, so i don't know what server is. like visualsvn, ubersvn...)
apache
mysql
php
using usvn to manage svn.

problem:

on checkout / update I can see the following message:

REPORT of '/ / /!svn/vcc/default': Could not read chunk size: connection was closed by server (http://***)

but actual update or checkout is successfully. just message.
and when I do update on same revision, no error.

And it is a little annoying but i can endure it. but real problem is when I try to commit. I can't commit.

when I try to commit, the committing takes very long time. at last, it failed. with next message. The message is showing my language so I don't know exact message. I translate it on English next :

Commit Failed: The server returned an unexpected value (400 Bad Request) to the MERGE '/svn/***/trunk' as a response to that request has been sent.

this problem only occurs with this client PC.
And the other client PC with this SVN server can't make problem.
And, the Client PC with other SVN server is never makes problem.
I reinstalled the TortoiseSVN over and over and remove it and clean the registry (with find Tortoise) and reinstalled but this problem continues. I don't guess this problem is caused by Server or Client.

Who knows solution of it?

Answer 1

thank you for your answers.
finally, i solved this problem other way.
the problem is on my client computer.

I using Kaspersky Internet Security my firewall.
I stop the real-time protection, and the commit/update/checkout succeeded.

but the some question still remains;why other svn server is no problem? i don't know the reason.

anyway, i'll try to solve this remaining question. because i want to use svn with my firewall.

Answer 2

Do you get this error if you check out a fresh working copy into a new directory? If not, then the problem is likely due to a corrupted working copy.

If a fresh WC can still reproduce this, then the problem may be on the server end. Do you have admin access to the server?

Answer 3

它在subversion.conf中的Timeout指令尝试将其设置为较低的值，例如3000000到3600。