From users-return-28089-archive-asf-public=cust-asf.ponee.io@subversion.apache.org Wed Jun 26 07:33:13 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 8138018064D for ; Wed, 26 Jun 2019 09:33:13 +0200 (CEST) Received: (qmail 8879 invoked by uid 500); 26 Jun 2019 07:33:11 -0000 Mailing-List: contact users-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@subversion.apache.org Received: (qmail 8868 invoked by uid 99); 26 Jun 2019 07:33:08 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 26 Jun 2019 07:33:08 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 80780C1768 for ; Wed, 26 Jun 2019 07:33:07 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.002 X-Spam-Level: ** X-Spam-Status: No, score=2.002 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=2, KAM_SHORT=0.001, NUMERIC_HTTP_ADDR=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=fmod-com.20150623.gappssmtp.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id MFLYkF5iVnqj for ; Wed, 26 Jun 2019 07:33:04 +0000 (UTC) Received: from mail-qk1-f195.google.com (mail-qk1-f195.google.com [209.85.222.195]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 2B42060D35 for ; Wed, 26 Jun 2019 07:33:04 +0000 (UTC) Received: by mail-qk1-f195.google.com with SMTP id s22so812664qkj.12 for ; Wed, 26 Jun 2019 00:33:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fmod-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/6cLW6Rv4R2OiX3fpZPCz+D9hl6E3YOuRrsPZy2+2pU=; b=dj4/gWI7RVkWgvEUTNF7rDO5alUg6UfC/+UaPyKFl1NZHlrKWwvWMR3yereO4GDhbG c4p50AbeHV5D4C4g+nIB05B78iYNwo78QfKTjuwz3tDRR98MJUknZaXcl49028E5EjgR chPhtg4lSz+7DO6mR09/IqCV0PbSIB0RvEA1Tpz6JYAYLrTV5dOzBj92TKqFob+8oijR fqM2GXu7EadSb3zs8d51sS7Vfih0Dkxj+nUVNnfXja74s2wYPzjVfWH3sLnUL9+yeYY6 IPqLJvknJPr34oAGQ9yiAcOZFpWRTyC7QPawCmYui88MPunTELVx/Eiu7I0ltoC343za SB6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/6cLW6Rv4R2OiX3fpZPCz+D9hl6E3YOuRrsPZy2+2pU=; b=LXLaFUREt+hVZLTNeVzMS+U2XC2DOQpSMGkDo8A6Q/oZYB0CVWVfZ7HYLdLd+29kN5 vzoIfSETV2lbuD2YAGBMOGNPevPUqBbWvw6RcmbtLDK+/cxEdOJrlqUdUBXBsZ6Qu5yX fWnC81vxFNs02DDUpUJdaGx6VcOEM8WRTDwgssvErbO70D/DlfHF20vROyOkEZgKP2kH SmN4JNOFwPODT1N6XDCZe60uYgZdO/IJIDqkT6D8UeMySZQEngfPc9Cw2uRxPxvZ9ciG SxEh395wxU7r6oleQ1V1TB6GjP9PlCBCywjE3QfUKe+Y6x7t/yBj5G5kmFGVYiNp81KV icXg== X-Gm-Message-State: APjAAAUiHTzI5XQCqEPPYoNA7U2DkrIinTXJr3hbbBAfdSHFAYSqHl9k mS9f/ffJXXe4sKvUuX6itecHTQGO56fKoxuN2fOx7w== X-Google-Smtp-Source: APXvYqxpriMnX0gIHxLkONgb0wE6jrHC73i2nLV6biGrq00kFpdC1D5AxJhGN0NHQUQ8tPqDRLqgPmBpLMmff6NFoug= X-Received: by 2002:a37:a80d:: with SMTP id r13mr2522232qke.209.1561534383099; Wed, 26 Jun 2019 00:33:03 -0700 (PDT) MIME-Version: 1.0 References: <785065892.20190613135937@am-soft.de> In-Reply-To: From: Thuan Seah Tan Date: Wed, 26 Jun 2019 17:32:26 +1000 Message-ID: Subject: Re: svn status and info slowness when multiple files are passed as args To: Johan Corveleyn Cc: Subversion , =?UTF-8?Q?Thorsten_Sch=C3=B6ning?= Content-Type: multipart/alternative; boundary="00000000000035bba0058c350e6d" --00000000000035bba0058c350e6d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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:///1.10/test2.txt" <-- slow svn info -r HEAD "svn://192.168.1.123/1.10/test.txt" "svn:///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 wrote: > On Thu, Jun 13, 2019 at 1:59 PM Thorsten Sch=C3=B6ning > 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-suit= e > > > > Mit freundlichen Gr=C3=BC=C3=9Fen, > > > > Thorsten Sch=C3=B6ning > > 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 issu= e > 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 > --00000000000035bba0058c350e6d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Apologies for the delay on this issue. I did more testing = and the following was my findings:

svn info -r HEAD &quo= t;svn://mysvnserver/1.10/test.txt" "svn://<server name>/1.1= 0/test2.txt" <-- slow
svn info -r HEAD "svn://192.168.1.123/1.10/test.txt&qu= ot; "svn://<IPv4 address of server>/1.10/test2.txt" <-- = fast

If I am not using the svn protocol and ju= st passing in the file path on disk, depending on how the files were checke= d out:

if checked out using Tortoise SVN and speci= fying 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 knowle= dge of whether a file was checked out using ipv4 or server name?
=


On Fri, Jun 14, 2019 at 12:13 AM Johan Corveleyn &= lt;jcorvel@gmail.com> wrote:
On Thu, Jun 13, 20= 19 at 1:59 PM Thorsten Sch=C3=B6ning <tschoening@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 i= t
> > 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 Pr= ocess
> 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.microsof= t.com/en-us/sysinternals/downloads/sysinternals-suite
>
> Mit freundlichen Gr=C3=BC=C3=9Fen,
>
> Thorsten Sch=C3=B6ning

Hm, I don't think the problem is "local IO slowdown" (like wi= th
antivirus). That wouldn't explain "svn info -r HEAD -R directory&q= uot;
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.s= html

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 p= roject (e.g. Tortoise SVN, Visual SVN, etc) and I should report the issue t= o them? Or is there some base client code used by these implementations?
Yes, there is "base client code" shared by all these implementati= ons:
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
--00000000000035bba0058c350e6d--