[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn status and info slowness when multiple files are passed as args

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Thu, 13 Jun 2019 16:13:23 +0200

On Thu, Jun 13, 2019 at 1:59 PM Thorsten Schöning <tschoening_at_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
Received on 2019-06-13 16:13:57 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.