Thorsten Schöning wrote on Mon, 24 Feb 2020 18:19 +0100: > During merges this regularly leads to conflicts which TortoiseSVN > tries to resolve by searching the repo for new merge targets and that > search is incredibly slow if executed remotely. > > I tried to do the same merge using 2 URL-merges with a local copy of > the repo and that was a lot faster.
If the remote repository uses https://, you could set up mod_dav_svn on localhost in a proxy configuration. For svn:// the equivalent would be to set up an svnsync mirror and do «svn relocate»'s to and from it by hand. In either case, this approach is a bit of a sledgehammer: it'll DTRT, but there may be an alternative solution that requires fewer resources. Cheers, Daniel > What is interesting is that it > seems things were CPU-bound within the TSVN-process, which makes sense > when accessing the repo locally using "file:///...". I didn't > recognize much disk I/O and have a SATA-SSD anyway. > > That makes me wonder because when doing the same remotely, I see > almost no CPU-usage nor disk-I/O on the remote server. I don't see any > heavy uploads or downloads on my network interfaces as well. This > sounds like whatever is done is done using lots of roundtrips to > contact the server and suffers from the latency of my somewhat slow > upload, rendering that feature almost useless in my environment. > > Is there anything I can do to optimize that? Something like tell the > SVN-client to upload whatever is needed to the server at once? Or is > there some break configured somewhere? During the operations my > upload is pretty constant at 40 KBit/s for only whatever SVN does.
