RE: SVN access became slow
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? Also: Why does SVNServe not provide an IPv6 service on our server PC? I think for now I will revert back to 1.9.7 on my main PC as well, until I have a better view of what's going on. -Original Message- From: Stefan Sperling [mailto:s...@elego.de] Sent: Tuesday 5 June 2018 15:34 To: Johannes van der Vegt Cc: users@subversion.apache.org Subject: Re: SVN access became slow On Tue, Jun 05, 2018 at 02:54:01PM +0200, Johannes van der Vegt wrote: > 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)? > Doing more wireshark sniffing: > - 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.
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 :-/
RE: SVN access became slow
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:s...@elego.de] Sent: Wednesday 6 June 2018 11:23 To: Johannes van der Vegt Cc: users@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 :-/
Re: SVN access became slow
On Wed, Jun 06, 2018 at 12:37:53PM +0200, Johannes van der Vegt wrote: > 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) The 1.9 binaries I used were not compiled by me and do indeed use a newer APR version. My 1.10 build is a custom build which happens to use an older APR version. > 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! OK, great. > 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. It's the same situation as if you were running a multi-process or multi-threaded SVN server, as is the case when Apache HTTPD is used with mod_dav_svn, or when multiple users commit at the same time via svn+ssh://. Running two svnserve in parallel is not an exceptional situation because it can happen at any time when svn+ssh:// repository access is used. With svn+ssh:// each client access spawns a new and separate svnserve process.
FINAL REMINDER: Apache EU Roadshow 2018 in Berlin next week!
Hello Apache Supporters and Enthusiasts This is a final reminder that our Apache EU Roadshow will be held in Berlin next week on 13th and 14th June 2018. We will have 28 different sessions running over 2 days that cover some great topics. So if you are interested in Microservices, Internet of Things (IoT), Cloud, Apache Tomcat or Apache Http Server then we have something for you. https://foss-backstage.de/sessions/apache-roadshow We will be co-located with FOSS Backstage, so if you are interested in topics such as incubator, the Apache Way, open source governance, legal, trademarks or simply open source communities then there will be something there for you too. You can attend any of talks, presentations and workshops from the Apache EU Roadshow or FOSS Backstage. You can find details of the combined Apache EU Roadshow and FOSS Backstage conference schedule below: https://foss-backstage.de/schedule?day=2018-06-13 Ticket prices go up on 8th June 2018 and we have a last minute discount code that anyone can use before the deadline: 15% discount code: ASF15_discount valid until June 7, 23:55 CET You can register at the following link: https://foss-backstage.de/tickets Our Apache booth and lounge will be open from 11th - 14th June for meetups, hacking or to simply relax between sessions. And we will be posting regular updates on social media throughout next week so please follow us on Twitter @ApacheCon Thank you for your continued support and we look forward to seeing you in Berlin! Thanks Sharan Foga, VP Apache Community Development http://apachecon.com/ PLEASE NOTE: You are receiving this message because you are subscribed to a user@ or dev@ list of one or more Apache Software Foundation projects.
Problem with svndumpfilter
I’m trying to remove two sensitive directories from a repo so we can have a 3rd party work on it. I first dumped the entire repo, and now I’m trying to remove two directories from one particular branch. But svndumpfilter keeps failing as follows: $ svndumpfilter exclude branches/develop/dir1 branches/develop/dir2 < repo.dump > repo-nodir12.dump svndumpfilter: E23: Invalid copy source path '/branches/develop/dir2' I’ve tried this both from a full incremental dump of the repo as well as a non-incremental dump of the repo starting from the revision that branches/develop was created. It always fails after the exact same revision. Is there anything I can do to work around this issue? Alfred
Re: SVN access became slow
Stefan Sperling wrote on Wed, 06 Jun 2018 15:18 +0200: > On Wed, Jun 06, 2018 at 12:37:53PM +0200, Johannes van der Vegt wrote: > > 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.
