A solution for the slow diff in (Tortoise)SVN?

Question

I often do code review in the following way:

1. Open the SVN log
2. Select a revision
3. Double click on a file...
4. ...and wait
5. See the changes
6. Goto 2 or 3 or finish

The 4th step is very annoying. Do you know a solution for this?

Answer 1

Buy a faster server for your repository? Just joking, but the reason for this problem might lie in the time Tortoise needs the retrieve the version from the server. I don't think the actual diff takes a lot of time.

Answer 2

It's interesting to note, perhaps, that this is one of the reasons git stores the entire history locally. I doubt switching to a different version control system is feasible for your project, but I thought I should mention that this feature allows you to perform diffs like this a lot faster.

Answer 3

A few questions which might help you to find out what is wrong:

• How long is the waiting in the 4. step? What is happening on-screen while you are waiting?
• what is your ping and bandwidth to the server?
• What diff utility are you using?
• What is the size of the files your are differencing?
• How old is the revision you are differencing?

My results:

• step 4. takes about 10 seconds, most of which is waiting for the file to be transferred (I can see the file transfer progress bar).
• my ping to the server is 20, bandwidth approx. 2 Mb/s
• I am using WinMerge. I remember with some other utils (e.g. DiffMerge) the comparison was very slow
• the file I am testing with is 23 000 lines / 725 KB.
• this is with last revision before head. With older revisions the step 4 can take longer.

If the step 4 takes about 10 seconds for you, than I would say nothing is particulary wrong with your setup, and have either to live with it, or to start using some kind of more distributed solution, as 80 ms ping is quite a lot (like Europe - USA) and you definitely will feel the delay. An alternative to fully distributed system could be to use SVN server replication and have a replicated server somewhere nearer your workstation (in the same room, in the same country, or if that is not possible, at least on the same continent would probably help).

Answer 4

The problem was at our server. I don't understand it fully, but our administrator said something about a module in apache, which via PAM's and SQL authorized the users. After some changes it works reasonably well.

Answer 5

From the various answers and comments, it looks like your main problem is latency/bandwidth with the centralized server. Here are a couple leads I suggest :

• Is your server served over http / https or over svnserve / ssh+svnserve. In my experience on pre 1.5 svn, the svnserve way was much faster than the http/https way for multiple file diff retrieval. If I recall correctly my investigation at the time, the http serving uses a protocol which needs a roundtrip to the server for each diff, while svnserve is able to send multiple diffs in one go.
• Is your client able to request multiple diffs at the same time ? (I think more specifically of the eclipse synchronize view which is able to request all the diffs for a tree and then let you review the files without further round trips.
• the last avenue of investigation I suggest is creating a readonly cache on your local machine, there are various ways to do that which have been explored in : How to synchronize two Subversion repositories?

Answer 6

Solutions:

• Git
• Mercurial
• Bazaar
• Darcs