[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

svn+ssh issues with svn 1.6.6 on windows (especially for svn-external repo)

From: Magnus Torfason <zulutime.net_at_gmail.com>
Date: Mon, 11 Jan 2010 11:53:55 -0500

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

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...

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

Received on 2010-01-11 17:54:36 CET

This is an archived mail posted to the Subversion Dev mailing list.