Hi, I am not sure whether this should go to the dev or users list, which according to the instructions means i should try here first :)
Im working on an client application that uses subversion as an internal component to sync data with a (SVN) server (through SharpSvn, though that doesn’t matter for this issue) using https. This client application might be working over an unstable connection (UMTS modem, poor wifi etc) so therefore we are of course testing what happens when the connection fails. We got a few very nasty surprise: If I pull the network cable out during an update operation (for example) the svn client will just keep waiting (for a very long time, probably the HTTP timeout default of 1 hour). This applies to both the SharpSVN library, the svn.exe commandline and TortoiseSVN. It is very easy to reproduce using the SharpSVN repository as an example: svn co http://sharpsvn.open.collab.net/svn/sharpsvn/trunk/ Wait until it starts receiving files, and then simply pull the network cable. If I set the http-timeout to a few seconds, it will timeout nicely. But then let's try an https repository instead: svn co https://xbmc.svn.sourceforge.net/svnroot/xbmc xbmc In this case it seems the http-timeout is completely ignored and it will hang for either a very long time or forever ( i didn’t bother waiting more than a few minutes). If I understand the use of the http-timeout correctly, it wouldn’t really help anyway, since SVN operations can take a while even if the connection is fine. What would help would be some kind of keep-alive to ensure that the client discovers that the server is no longer reachable. The problem seems very much related to issue 3347 which is related to the client hanging when the public IP changes ( see http://subversion.tigris.org/issues/show_bug.cgi?id=3347 ). However it seems this was only fixed for the svn protocol ( using TCP keep-alive if i understand correctly), but i seem to be having the same issue with svn+ssh (just tested with TortoiseSVN against our own development trunk). I have also tried configuring svn.exe (version 1.6.6 and 1.6.12 both from the Visual SVN installer) to use serf ( using "http-library=serf" in global section of servers file instead of setting timeout ). In this case svn.exe just crashes(!) after waiting 30 seconds or so (message is "svn: Error retrieving REPORT (20014): Internal error"). This seems somewhat more promising in that it actually notices that something is wrong, now i just need it to stop crashing ;) Regards, Peter Tiedemann Details regarding setup: I have build svn.exe 1.6.12 myself as well as used 1.6.6/12 from the VisualSVN package and verified the problem there as well as with the latest SharpSVN snapshot and TortoiseSVN 1.6.9. The OS is Windows 7 64-bit. There are no proxies or similar complications.