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 <jcor...@gmail.com> wrote: > On Wed, Jun 5, 2019 at 4:15 AM Thuan Seah Tan <th...@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 >