I wanted to send a word to the developers about strange behavior by
Subversion on Windows when using svn+ssh to connect to an external
(linux) host, with repositories that contain a number of svn-externals
entries.
I recently upgraded both SlikSVN and TortoiseSVN from 1.6.1 to 1.6.6.
After the upgrade I found intermittent problems with running svn update
(TSVN), and a persistent problem with running svnsync (SSVN).
I will go through each of them in turn below, because it seems to me
that they might be related (although I'm not sure).
1: svnsync (through SSVN):
A svnsync process from an external server that had always worked did no
longer complete successfully. The error message was:
plink: unknown option "-q"
Connection terminated
I don't know whether the plink error came from plink or if it is a
pass-through from some other process, but looking at the plink
documentation, I can't see that there has ever been a "-q" option.
Resolution: I downgraded SlikSVN to 1.6.5, which did not resolve the
issue. However, after downgrading all the way down to 1.6.1 again, this
issue seems to have been resolved.
2: svn update (through TSVN):
At the same time, I started having intermittent "connection refused"
problems when updating my repository from the same server. This always
happened while updating one of the several svn-external directories that
I have as part of my repository. After the error, I could not ssh into
the server either, until after a few minutes. Downgrading to 1.6.1 did
not resolve this problem.
Resolution: None that is entirely satisfying.
Workaround: Choose "Omit externals" when updating.
Further thoughts: After reading the thread on Issue #2580 I started
wondering if the issue might be caused by a quota on open/hanging ssh
connections that was enforced by the server (I'm not an admin on the
server so I can't do much to look into that). But if the following is
the case:
> Instantly killing the tunnel (clearly the WRONG way to
> terminate a TCP connection!) sets off a chain of events, ALL
> OF WHICH ARE ERRORS. The svn protocol does not complete
> normally, nor does the ssh protocol, nor does the TCP
> protocol! Do we want EVERY SINGLE svn+ssh connection to
> complete through error paths? That's what's happening now,
> to EVERYONE who is using svn+ssh from a Windows client! I've
> already explained why we haven't gotten more complaints.
>
> But I repeat: instantly killing the tunnel upon receipt of
> the last SVN data from a remote svnserve is NOT the way to
> shut down the connection between the two. It leaves the
> remote sshd wondering what happened and sitting there
> waiting for the next step in ITS protocol (SSH). It has no
> idea what is coming next (more data or what???). So it sits
> there waiting...
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2410204
Then it seems reasonable that defensive measures by server
administrators might lead to this problem in the case of a number of ssh
connections being rapidly opened and then closed in an unclean manner
(since svn-update seems to open a new connection for each svn-external
entry).
Best,
Magnus
Received on 2010-01-11 17:54:36 CET