Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

SVN/TortoiseSVN painfully slow

I'm experiencing painfully slow operations with one of our SVN repositories/projects.

For example, it's taking 5-10 minutes to revert the changes in one small file (10 KB). Or about 40-60 minutes to check out the project of 100 MB.

There are about 30 other projects on the same server, some vastly bigger than this one, and none of them preform like this.

One thing to note is that this project is a Magento project. It's not very large in terms of disk space, but I have 23k Files and 11k folders, and I have read SVN preforms badly when there are lots of little files; is this true? And is there anything I can do to speed things up?

like image 988
Dan Avatar asked Jun 04 '09 09:06

Dan


People also ask

Why is SVN so slow?

The key argument is that SVN due to its support for atomic transactions needs to do many more file operations than CVS in order to ensure integrity. This makes it slower than CVS, especially if there is an on-access virus scanner involved.

How do I get rid of TortoiseSVN?

How do I uninstall TortoiseSVN? Simply uninstall from Add/Remove Programs in the Windows control panel. This does not affect your repositories or working copies at all.

What is TortoiseSVN status cache?

TortoiseSVN cache process checks repository checkouts for changes and displays nice overlay icons in Windows Explorer. Instead of disabling the cache, you can optimize the paths where TSVNCache.exe looks for repositories so it only actually looks at working copies and not your whole disk(s) drive(s).

What is the difference between SVN and TortoiseSVN?

The main difference between SVN and TortoiseSVN is that the SVN is a distributed version control system while TortoiseSVN is an SVN client implemented as a Microsoft Windows shell extension. In brief, SVN is a version control system. On the other hand, TortoiseSVN is a Subversion client.


1 Answers

The Subversion working copy performs quite badly when there's a huge number of directories, like in your case. For write operations (even only locally) to the working copy, the working copy has to be locked, which means that a lock file is created in every directory (that's 11k file creates), then the action executes, and the those 11k files are deleted again.

Subversion 1.7 is moving to a different working copy format, that should resolve these problems. Until then there's a few tricks you might try to speed things up, like excluding the working copy from your virus scanner, disabling file monitors on the directory (like TortoiseSvnCache), and trying to reduce the total number of directories. (Perhaps by checking out a few separate working copies)

like image 75
Sander Rijken Avatar answered Sep 24 '22 23:09

Sander Rijken