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
