Hi Johan,
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?
I ran 'svn info --show-item url' as requested and the url showed the svn://
protocol. 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".
On Wed, Jun 5, 2019 at 8:05 PM Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> On Wed, Jun 5, 2019 at 4:15 AM Thuan Seah Tan <thuan_at_fmod.com> wrote:
> >
> > Thanks for the response. I did more testing on the 1.12.0 server, and it
> seems it's only those command options that I think would require querying
> the server is experiencing the slow down:
> >
> > e.g.
> > svn status --show-updates directory/file1.txt directory/file2.txt
> directory/file3.txt <-- this took about 3 seconds and seems to scale
> according to the number of files as it outputs "Status against revision"
> for each file.
> > svn status --show-updates directory <-- this took about 1-2 seconds but
> only output "Status against revision" once.
> >
> > svn info -r HEAD directory/file1.txt directory/file2.txt
> directory/file3.txt <-- this took about 3 seconds and seems to scale
> according to the number of files and display info for each file at the rate
> of 1 file per second
> > svn info -r HEAD -R directory <-- this took about 1-2 seconds even
> though the entire directory has 17 files and just outputs info for 17 files
> in one hit
> >
> > The server is on another machine in my local network and both running
> Windows 10 Pro. Not entirely sure the filesystem you are referring to, but
> the drive with the repository is running NTFS.
>
> Is your client also version 1.12.0? Running 'svn --version' on the
> client will tell.
> It's just to eliminate that this was possibly optimized on the client
> side in recent versions.
>
> A couple of other things come to mind:
>
> - It's possible that 'svn status --show-updates X Y Z' opens
> (sequentially) 3 separate connections / sessions to the server,
> instead of only 1. Same for your 'svn info -r HEAD' example. That's
> something that could possibly be optimized in the client.
>
> - How come it even takes 1-2 seconds for a single 'status
> --show-updates' or 'info -r HEAD' request? That's extremely slow,
> especially since you're saying it's all on a local network. Is it fast
> if you create a working copy with a file:/// URL directly on the
> server, and perform those commands there (it should be fast)? What
> protocol are client and server using? Running 'svn info --show-item
> url' on your working copy should tell. If it's https://, maybe there
> is some problem / slowdown when opening a new SSL socket? Or
> performing LDAP authentication on the server side. If it's svn://,
> maybe there is a problem with IP v6 vs. IP v4.
>
> --
> Johan
>
Received on 2019-06-13 09:26:22 CEST