On 2005-10-24 14:49:44 +0100, Paul Brook wrote: > The combination of svn+ssh and automatic ssh connection caching is > broken. > > In my ~/.ssh/config I have > > ControlPath /tmp/.ssh-%h-%p-%r > ControlMaster auto
You're not allowed to do that as the master connection will close any slave connection. More precisely, the following behavior may happen with a single svn command: 1. The subversion client does a first ssh connection. A master ssh connection is automatically opened. 2. The subversion client does a second ssh connection. A slave connection is opened. 3. The subversion client closes the first ssh connection. This closes the master *and* the slave connections. So, svn fails. This is definitely not a Subversion bug here. Of course, ssh should be improved. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=335697 (this is unrelated to the ssh bug you filled). > Looking at strace output it appears that svn very rudely terminates its > child processes with SIGKILL. This makes ssh leave stray connection > state files lying around. This part may be a bug in Subversion, though. But if you start the master connection manually (svn -fMN ...), there are no problems. > Arguably this is a ssh bug (separate bug filed), but svn really should > give the child process chance to exit gracefully. I don't think this (bug 335531) is a ssh bug. Overwriting the files could lead to a race condition in a "normal" use. Anyway, "fixing" this bug only won't solve your problem, as I've explained above. -- Vincent Lefèvre <[EMAIL PROTECTED]> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / SPACES project at LORIA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
