SVN access became slow

[Stefan Sperling]

Right... I installed a second service with the '-6' option. This did not
make any difference.

Why does this not work? This should work. Can you connect to the
SVN service with telnet to the server's advertised IPv6 address
on port 3690? Maybe svnserve is not listening on the correct
IOPv6 address (see the --listen-host option)?

- At first, SVN client tries connecting from the local-link IPv6 address.
There is no response. Two TCP retransmissions fail as well.
- Second, SVN client tries connecting from the temporary IPv6 address. There
is no response. Two TCP retransmissions fail as well.
- Finally, SVN client falls back to IPv4. This is successful.
The other client PC (Win10 Home 1803) runs an older SVN client (v1.9.7), and
does not try IPv6 first; this one goes straight to IPv4. Running the 'svn
info' command from that older version on my own PC also goes straight to
IPv4.
I believe there is no option to force the client to use IPv4?? (except
specifically entering the IPv4 IP address)
Have I found a bug?

I don't think there is a bug here. SVN will simply try addresses
returned by your client system's DNS resolver in turn. Maybe you
could configure your client system's DNS resolver to prefer IPv4
but that would not be a nice solution.

If your SVN server has an IPv6 address but does not provide service
on that address, this is expected behaviour. There is no way for
the SVN client to know that it should not be trying this address.

If you do not intend to provide SVN service over IPv6, you could
also disable IPv6 entirely on the SVN server machine.

[Daniel Shahaf]

Post by Stefan Sperling
If your SVN server has an IPv6 address but does not provide service
on that address, this is expected behaviour. There is no way for
the SVN client to know that it should not be trying this address.

Well, connecting to the IPv6 address on TCP port 3690 could return a TCP
RST or an ICMPv6 "Host unreachable" or the like, as opposed to no
response at all (which I presume is what wireshark is showing).

[Stefan Sperling]

Post by Daniel Shahaf

Post by Stefan Sperling
If your SVN server has an IPv6 address but does not provide service
on that address, this is expected behaviour. There is no way for
the SVN client to know that it should not be trying this address.

Well, connecting to the IPv6 address on TCP port 3690 could return a TCP
RST or an ICMPv6 "Host unreachable" or the like, as opposed to no
response at all (which I presume is what wireshark is showing).

Yes, it sounds like something might be dropping packets somewhere.

[Stefan Sperling]

Ok, I have the two instances running simultaneously now, and everything
seems to be working. I trust your advice, backed by Daniel Shahaf, that this
is a normal and proper situation.
About the slow 1.10.0 client experience I had: trying IPv6 first and then
falling back to IPv4 is normal, you told me, correct?

This depends on the choices taken by implementors of the
operating system's DNS resolver. It has nothing to do
with either SVN or APR (unless APR's DNS API wrappers
change the results returned from the system for some
reason, but I'd doubt it was doing that).

And (Tortoise)SVN 1.9.7 went straight to IPv4 because of APR 1.5.2? Does APR
1.5.2 not support (or not default to) IPv6?

I don't know, and I don't have time to find out.
You could ask this question to the APR project: https://apr.apache.org

Then a lot of users must have ran into this issue, right? Namely: Every user
running an APR 1.5 SVN server, and a (Tortoise)SVN 1.10.0 client.

Most servers use Apache HTTPD which supports dual-stack operation.
This problem is specific to server deployments using the svn://
repository access method on IPv6-enabled servers.

Well, my issue is solved now. Thanks for the support!!!

Glad we could help. You're welcome :)

[Daniel Shahaf]

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?

No, that is not a problem. Writes to the same repository from
different processes are always serialized properly.
[...]

As Stefan said, having multiple, concurrent readers and writers is 100% supported.

At the network level there is no problem either. The IPv4 and IPv6
stacks are independent; the TCP/IPv4 and TCP/IPv6 sockets happen to use
the same port number, but that's not a problem in any way; it's exactly like
running two TCP/IPv4 listening sockets on different port numbers.