4

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?

Michal Czardybon
  • 2,685
  • 4
  • 27
  • 39
  • 1
    Is your SVN server remote? Local Network? Local machine? – Oded Mar 18 '10 at 08:17
  • The server is remote as I work off-site. However, when I get local, the things don't change much. – Michal Czardybon Mar 18 '10 at 08:28
  • We are facing the same problem here. For comparing a file of, say 5 kB size, the diff command (Step 3 above) is transferring 2.4 MB of data. Our server is remote but why should it transfer more than 100 times data of size of a file? We have https in the URL, can that be cause of this (encryption)? – pongapundit Jan 21 '19 at 14:34
  • I used SVN about 2 years back, but then it was not as slow. Did something go wrong in recent versions. My SVN version is - TortoiseSVN 1.11.0. – pongapundit Jan 21 '19 at 14:39

6 Answers6

2

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.

nfechner
  • 16,559
  • 7
  • 43
  • 63
  • Yes, the problem is about the communication with server. But what is the solution? – Michal Czardybon Mar 18 '10 at 08:26
  • 1
    Over-simplified answer: There isn't one. More complex answer: It depends on your connection to the remote server. Do you use a VPN, that might slow the connection down? Do you have a slow internet connection? How high is the network/processor/io load on the server? You need to identify the bottle neck first to do anything about it. – nfechner Mar 18 '10 at 08:35
  • I thought there might be some solution using some kind of offline caching of the diff results. – Michal Czardybon Mar 18 '10 at 12:48
1

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.

wds
  • 30,210
  • 11
  • 54
  • 81
  • The OP didn't specify whether he was willing to switch to a different version control system or not. If you're going to downvote, at least leave a comment... – wds Mar 19 '10 at 18:56
  • svk also stores history locally, while being built on top of svn and providing compatibility – Ben Voigt Mar 19 '10 at 19:00
0

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).

Suma
  • 30,270
  • 14
  • 115
  • 176
  • - step 4. takes about 10 seconds; I see "Getting information..." and the "Getting file" - My ping to the server is 80 ms - I use standard Diff, which comes with TortoiseSVN - The files are usually 100-1000 loc - I usually check files near the head – Michal Czardybon Mar 18 '10 at 12:14
  • What transfer rates do you see in the progress window? Do they seem reasonable knowing your connection and server connection to the internet? – Suma Mar 18 '10 at 20:07
0

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.

Michal Czardybon
  • 2,685
  • 4
  • 27
  • 39
0

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?
Community
  • 1
  • 1
Jean
  • 20,591
  • 5
  • 43
  • 61
-2

Solutions:

yfeldblum
  • 63,188
  • 11
  • 126
  • 168