On Thu, Jun 13, 2019 at 1:59 PM Thorsten Schöning <[email protected]> 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
