Slow Network Transfers With TortoiseSVN

I had a problem with TortoiseSVN being incredibly slow with file transfers from the local SubVersion server. The symptoms were as follows:

1. An extremely long delay (around 20-30 seconds) when entering any screen that interacts with the SVN server (e.g. Repository Browser, Show Log, etc...). The windows wait cursor would wait and wait and wait.
2. Extremely slow file transfers when updating, committing or exporting anything from the repository to the local disk. File transfers were coming down no faster than 10 kb/sec.

No other programs were affected, and even browsing the repository through the web browser was nice and quick. Internet download speeds and windows network file transfers were nice and quick. So the problem was specific to either TortoiseSVN itself, or the SVN browser. I had done the following to try and correct the problem (without success):

1. Updated all Ethernet drivers.
2. Applied all Windows updates.
3. Updated TortoiseSVN to the latest version (twice).
4. Ran disk utilities (scandisk, etc...).
5. Stripped out all unnecessary background applications.
6. Modified the MTU settings.
7. Removed and freshly exported all SVN projects.
8. Removed and freshly generated all security certificates (for https:// SVN transfers)

Having upgraded TortoiseSVN twice, and seen no improvement, the only thing left that could be causing the problem was the SVN server itself. And yet, my colleague here in work was not experiencing any problems with it. Nevertheless we upgraded the Operating System which the SVN server was on from Windows Server 2003 to Windows Server 2008. The result? Nothing - still the same problems. I was ready to re-format my computer and start again when our network administrator quite by accident noticed something odd about the SVN server. A tracert and ping to it would fail at the command line, despite the fact that it was clearly working within the Windows XP shell. So we did an nslookup on the server and got the following information display:

Server: UnKnown
Address: 192.168.1.117

Name: svnserver.ourdomain.com
Address: 192.168.1.115, 192.168.3.57

Our SVN server appeared to be using 2 IP addresses, one of which was not responding at all. I checked my colleague's computer and his was showing the same thing - 2 IP addresses! And yet his was working OK.

But his IP addresses were being displayed in a different order to mine. The working IP address (192.168.3.57) was displayed first on his computer, and second on mine.

The order of the IP addresses is critical. My computer was always checking (and waiting) for the first IP address to respond. When it timed out (after around 30 seconds), it then tried the second address which instantly responded. My colleague's computer always responded when checking the first address, so never had any need to switch to the alternative address.

It turns out that the second non-working IP address was a hangover from a recent server relocation. The network administrator had to sort out the Network configuration properly on the server and a quick restart later the server was only displaying one working IP address to nslookup requests.

The result? Tortoise SVN instantly started working correctly again. Not even a reboot was necessary.

Thank goodness for serendipity.