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 <jcorvel_at_gmail.com> wrote:
> 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-26 09:33:13 CEST