[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Having a problem with TortoiseSVN: taking long time!

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: Fri, 27 May 2016 22:48:55 +0200

On 27.05.2016 15:13, 井戸里志 wrote:
> Hello,
> I am currently having a problem with TortoiseSVN. When I try to run “Check for modifications”, for example, it would take extremely long time: from the state of “Please wait…” to finally display the file list. This occurs with some of my folders.
> Some folders, though with the same repository and almost the same size and number of files, seem to take longer time for “Check for modifications” than others. Some folders (approximately 4GB) may take a few seconds, while others with the same sizes would take about 5 to 10 minutes to complete the processing. In case of a 100GB folder, it would take, say 2 hours.
> Among the folders taking longer time, those of smaller sizes tend to take less (or no) time once "Check for modifications" is completed.
> On the other hand, folders with the size of 10GB or larger would take just around the same long time even once “Check for modifications” is completed. Moreover, other folders that has been through Check for modifications and have no problem afterwards will be reverted back to the taking longer time state!
> The same phenomena happen not only with “Check for modifications”, but also all the other processes relating to show the file list of “Working copy”, such as “Commit” and “Resolve”.
> On the other hand, it would not take that long time with “Update” as long as the difference is small.
> This phenomenon takes place in other repositories using different servers.
> However, it does not happen in the other user environment who has checked out the same repository--and it wouldn’t take longer than 10 seconds to complete the processing.
> I don’t know exactly what factors about folders would cause this phenomenon, but it seems to happen only with the repositories that has been checked out recently.
> The version of TortoiseSVN is 1.9.3. The phenomenon happened in the version 1.7.9 so that I updated to the recent version but the problem was not fixed.

Check if the files have their last-modified-time changed even though the
content has not.
Have a look at how svn detects modifications:

if the file time has changed but the file content has not, svn has to
open that file and compare it byte-by-byte to find out whether the file
was modified or not. For many files and big files that can take a long time.

To fix the time stamps on the files, open the cleanup dialog and check
the box "fix time stamps", then click OK to run the cleanup.
After that it should be fast again.

> The setting of LogCaching is Power user default.

log caching isn't at play here.

> The setting Icon Overlays as shown below:
> Status cache=Default
> Include paths=limited to the minimum, a total of approximately 340,000 files.
> Drive Types= all unticked.

Also does not have an impact on the status dialogs.

> HDD: I use D drive. The size of D drive is 1.33TB, with available capacity of 137GB.
> Speed of reading and writing contiguous data: 70-90 MB per second.
> Speed of random access per 4KB: 0.4-0.9MB/ second.

Seems fast enough.
But there one other factor that has a huge impact on speed:
virus scanners
They scan the files TSVN opens to check if they're modified. So if they
scan every file first and block TSVN from opening it, TSVN has to wait
until the file can be read. For many files, that sums up.
Configure your scanner to not scan your working copies.


   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest interface to (Sub)version control
    /_/   \_\     http://tortoisesvn.net
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2016-05-27 22:49:02 CEST

This is an archived mail posted to the TortoiseSVN Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.