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

Workaround for slow RepositoryBrowser on large repositories

From: Schnyder Franz <schnyderfranz_at_gmail.com>
Date: Fri, 11 Jan 2013 13:03:13 -0800 (PST)

We use the TortoiseSVN (1.7.11) with various internal repositories (Subversion 1.6.16) and the Repository Browser is very slow, more than 2 minutes to show the initial screen, on larger repositories. I already disabled the RepoBrowserPrefetch and the RepoBrowserShowExternals flags but this did not show the hoped for performance improvement. We also see that a Repository Browser generates quite a CPU load on the server.

I found the fixed Issue 180 "Optimize repo browser for big repositories" and saw that the “incomplete” fetch is only used when fetching the URLs up to the root and not for the rest. So I got the TortoiseSVN code of the 1.7.11 tag and changed the Repository Browser so it always uses the incomplete fetch for all SVN::List (dirent_fields=0x0) calls. But again the performance did not improve much.

In a next attempt I changed the fetch_locks parameter inside SVN::List to always be false. I now the repository browser starts in a 1 to 2 seconds! I reverted the change to use the incomplete fetch for all SVN::List calls and it still starts within 2 seconds. The only thing I loose is the info in the Lock column.

So it looks like the fetch_locks causes the performance problem. I’m not sure where root cause of the problem lies (Subversion, Server, TortoiseSVN) but my change is a workaround for the problem.

Has anyone ever discovered similar performance problems or heard/read from problems with the fetch_locks flag?

I will try to clean up my code changes and introduce an RepoBrowserFetchLocks flag so TortoiseSVN users with the same problem than I, then could disable the lock fetching.

Is there interest in such a patch?

And is there a chance to integrate it into the official TortoiseSVN version, because for us it would be nice to have this workaround in the official version, so we don’t have to manage our own TortoiseSVN version?



To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2013-01-11 22:18:13 CET

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