The APR version gave me a hint in the right direction.
Client SVN linked dependencies:
SVN 1.10.0: - APR 1.6.3 (compiled with 1.6.3)
SVN 1.9.7: - APR 1.5.2 (compiled with 1.5.2)
(Did you mix up 1.10 and 1.9 in your list? Because my version numbers are
swapped w.r.t. yours)
On the server:
SVN 1.10.0: - APR 1.5.1 (compiled with 1.5.1)
This was a version downloaded from CollabNet.
I installed TortoiseSVN with the command-line-tools on the server. That gave
the following version info:
SVN 1.10.0-dev: - APR 1.6.3 (compiled with 1.6.3)
Starting the server:
svnserve -d --listen-port 3690 -6 -r "D:/[RepoPath]"
IT WORKS!!! I now have an ipv6 service running, and accessing it from my
main PC is fast!
But... Can I have two processes (IPv4 and IPv6) running on the same port
together? And will they access the same database on the driver? That may
give trouble if two users connect simultaneously, right?
@Stefan: Thanks for your time in supporting this so far!!.
-----Original Message-----
From: Stefan Sperling [mailto:stsp_at_elego.de]
Sent: Wednesday 6 June 2018 11:23
To: Johannes van der Vegt <Johannes.van.der.Vegt_at_applicos.com>
Cc: users_at_subversion.apache.org
Subject: Re: SVN access became slow
On Wed, Jun 06, 2018 at 10:08:58AM +0200, Johannes van der Vegt wrote:
> I do "Telnet \\server 3690", and I get:
> Connecting To \\server...Could not open connection to the host, on
> port
> 3690: Connect failed
> I haven't used Telnet before, so maybe I'm doing something wrong?
>
> Running TCPView tool(from SysInternals) shows svnserve.exe with
> protocol 'TCP' on port 3690, while other ports (other services) do show
'TCPV6'.
>
> I installed SVN 1.10.0 client on the other client PC, and this also
> gets slow. Reverting to 1.9.7 solves this again (because it goes
> straight to IPv4).
> I'm puzzled... Why is 1.10.0 showing this behavior?
If svnserve is indeed not listening on an IPv6 socket even though the -6
option was provided, then that is unexpected behaviour.
There weren't any changes in svnserve between 1.9 and 1.10 which could
explain this, though, and it works as expected in a quick test on my system
(OpenBSD 6.3) with both SVN 1.10 and SVN 1.9:
$ netstat -an -finet6 | grep 3690
tcp6 0 0 *.3690 *.* LISTEN
If you can confirm that you're indeed seeing unexpected behaviour, then this
behaviour may depend on which version of APR was linked to svnserve because
svnserve is opening sockets via APR. The command 'svn --version -v'
should show the APR version under 'linked dependencies'.
The APR versions used by the SVN builds I've just tested successfully are,
respectively:
SVN 1.10: APR 1.5.2 (compiled with 1.5.2)
SVN 1.9: APR 1.6.3 (compiled with 1.6.3)
> Also: Why does SVNServe not provide an IPv6 service on our server PC?
As I mentioned before, svnserve does not support both IPv4 and IPv6 at the
same time. See https://issues.apache.org/jira/browse/SVN-2382
As documented there I made an attempt to add dual-stack support almost
10 years ago. There is no reason why it couldn't be made to work but I
failed at it back then and gave up on solving this task.
Starting one svnserve process per address family is the best workaround and
I am surprised that it does not work for you :-/
Received on 2018-06-06 12:38:25 CEST