Apologies for the delay on this issue. I did more testing and the following was my findings:
svn info -r HEAD "svn://mysvnserver/1.10/test.txt" "svn://<server name>/1.10/test2.txt" <-- slow svn info -r HEAD "svn://192.168.1.123/1.10/test.txt" "svn://<IPv4 address of server>/1.10/test2.txt" <-- fast If I am not using the svn protocol and just passing in the file path on disk, depending on how the files were checked out: if checked out using Tortoise SVN and specifying the repository server as "svn://192.168.1.123": svn info -r HEAD "C:/1.10/test.txt" "C:/1.10/test2.txt" <-- fast if checked out using Tortoise SVN and specifying the address of the server as "svn://mysvnserver": svn info -r HEAD "C:/1.10/test.txt" "C:/1.10/test2.txt" <-- slow Wondering if using the server name defaults to IPv6. I suppose that's up to the router's configuration? When checking out files, is there something added to the .svn folder that retains the knowledge of whether a file was checked out using ipv4 or server name? On Fri, Jun 14, 2019 at 12:13 AM Johan Corveleyn <jcor...@gmail.com> wrote: > On Thu, Jun 13, 2019 at 1:59 PM Thorsten Schöning <tschoen...@am-soft.de> > wrote: > > > > Guten Tag Thuan Seah Tan, > > am Donnerstag, 13. Juni 2019 um 09:25 schrieben Sie: > > > > > [...]I also tried running 'info -r HEAD' on files > > > that are checked out on the PC that the server was running, and it > > > is just as slow. Both the url and repository root fields started with > "svn://localhost". > > > > As you are running Windows, disabling all kinds of AV-software at > > least for the directories belonging to your SVN-repos would be the > > first thing I'm trying. If that doesn't change a thing, use Process > > Monitor to see where the slowness comes from. That reports exactly > > which I/O happens where and how long it takes. > > > > https://docs.microsoft.com/en-us/sysinternals/downloads/procmon > > > https://docs.microsoft.com/en-us/sysinternals/downloads/sysinternals-suite > > > > Mit freundlichen Grüßen, > > > > Thorsten Schöning > > Hm, I don't think the problem is "local IO slowdown" (like with > antivirus). That wouldn't explain "svn info -r HEAD -R directory" > taking 1-2 seconds (in the initial report by the OP). > > @Thuan: has it always been that slow? > My intuition tells me to take a look at IPv4 vs. IPv6 problems. See > for example this thread on this mailinglist: > https://svn.haxx.se/users/archive-2018-06/0000.shtml > > Also, in response to your question: > >> I am using Tortoise SVN 1.12.0 r1857323. When you say it could be > optimized in the client, I take it that is up to the team maintaining the > project (e.g. Tortoise SVN, Visual SVN, etc) and I should report the issue > to them? Or is there some base client code used by these implementations? > > Yes, there is "base client code" shared by all these implementations: > TortoiseSVN, Visual SVN, commandline SVN, ... they all share the same > underlying svn libraries that are maintained by this project, Apache > Subversion (of which you've reached the users mailinglist). > > As for "reporting the issue to the team maintaining the project": > there is not really a dedicated "team" waiting to work on issues. > There are project members of the Apache Subversion project (some of > them are also reading this mailinglist -- I am one of them). Those > project members are just individuals like yourself, sometimes working > on things they care about (for themselves or for their employers) ... > such is the nature of FOSS. So reporting an issue or suggesting an > improvement will not magically make it happen. On the other hand, we > very much appreciate clear reports of issues or suggestions -- those > are definitely valuable contributions. > > In other words: yes, it could be a good idea to officially write this > down into an issue in the issue tracker [1] (but we're still a bit > fuzzy on the details, I think we still need some further discussion / > troubleshooting), but to make expectations clear: reporting it does > not magically make it happen :-). > > [1] http://subversion.apache.org/reporting-issues.html > > Thanks, > -- > Johan >
