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.
Received on 2020-02-24 18:27:47 CET