On Sat, Jun 19, 2010 at 10:54:54AM +0100, Graham Reeves wrote:
> On 18 June 2010 17:07, Bob Archer <Bob.Archer_at_amsi.com> wrote:
>
> > > > Hi All,
> > > >
> > > > I currently have a problem when using JetBrain's TeamCity (see this
> > > thread;
> > > > http://www.jetbrains.net/devnet/message/5265757 ).
> > > >
> > > > I'm running svnserve as a daemon on OSX leopard(1.5.6, NOT snow
> > leopard)
> > > Please update to 1.6.11. We enabled TCP keep-alives in svnserve in
> > > that release to hopefully fix forever-blocking reads from sockets.
> > >
> > > Stefan
> > >
> > > Fantastic, thanks, I'll try this ASAP.
> > > I only downloaded that version (1.6.6) a few days ago, maybe collab.netis
> > > a bit slow to update their package.
> >
> > CollabNet current d/l's for OS X are 1.6.11. However for my Mac I find it
> > easier to get subversion with MacPorts. The port is updated fairly quickly
> > after svn revs. Much thanks to whomever maintains that.
> >
> >
> My mistake, I *am* running 1.6.11...
>
> We have found that changing team city to use localhost instead of the
> external address (which eventually resolves to the same machine) that the
> problem goes away and the processes are closed. This is the path...
>
> TeamCity (on fry.local) checks out/get-latest-rev's to XXX.getmyip.com -> My
> modem -> My Router -> Port-forwards to fry.local
>
> XXX.GetMyIP.com being an address from dyndns. Tortoise and svnx don't cause
> this problem when using the external address.
>
When your external IP changes during a running svn connection,
svnserve has no way to tell whether the client is still busy
or can't get through. TCP keep-alives only work if the server
can still reach the client at the network layer.
But since your problem with team city seems to be frequent I doubt
is what's causing trouble.
> Does anyone have any ideas of what I could debug?
Without knowing what svn client implementation teamcity is using,
it's hard to tell what's going wrong.
You could compare tcpdumps from different sessions, one using the
standard svn client, and one using team city.
Maybe ask the teamcity people for help?
And just to make sure, you are using plain svn://, not svn+ssh://, correct?
That makes a whole lot of difference, because with svn+ssh, ssh is
managing the TCP connection on behalf of svn.
Stefan
Received on 2010-06-19 12:46:50 CEST