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

svn (switch) never times out when public IP changes

From: Christian Lohmaier <cloph_at_openoffice.org>
Date: Fri, 2 Jan 2009 21:17:16 +0100

Hi *,

Problem: When the internet connection is cut during a svn switch[1],
the command never returns. It doesn't quit with an error, nor does it
recover and finish. It just sits there and does nothing and has to be
killed. "never" means way more >60 hours.

Details: The clients are nated to the net, the router gets a new IP
every 24 hours (forced-disconnect by the ISP[2]), the repository is on
a different network with fixed IP, access method is svn://
Problem occurs on Fedora 64bit (svn 1.4.6 from the distro), a Mandrake
system with svn 1.5.4 (selfcompiled) and on Mac OSX 10.4 (PPC) with
svn 1.5.4 (opencollab.net binary). The Fedora box is on a totally
different location than the Mac and the x86 linux, not attached to the
same router. The Linux machine nats the Mac and is itself nated by the
router (but tried with having the Mac nated by the router as well, no

cvs on the other hand just did time out, so that one could react on
the failure (cvs could not complete the operation), i.e. simply run
the cvs command again. (On the same Machines, access method pserver,
no ssh-tunnel)

In fact no other software ever did show similar behaviour. Either the
software just resumed/recovered by itself or it did quit with error
(like cvs). But no software did just sit there and never return.

Ideas, comments, questions?

[1] switch is just what the machines happen to use, did not try with
checkout (doing a full checkout is way too slow compared to unpacking
a tarball or an existing checkout and then using svn switch)
[2] Problem occurs as well when manually cutting the line


To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-01-05 13:55:45 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.