views:

3355

answers:

6

I'm experiencing painfully slow operations with one of our svn repositories\projects.

For example its taking 5-10mins to revert the changes in one small file (10 KB). Or about 40-60mins to check out the project of 100Mb.

There is about 30 other project 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, its not very large in terms of disk space but I has 23k Files and 11k Folders and I have read SVN preforms badly when there are lots of little files, is this true? and its there anything I can do to speed things up?

A: 

What repository format are you using on the server? FS? BDB? You could try a different one?

1800 INFORMATION
This can't be the problem, because reverting is a local-only operation
Sander Rijken
+1  A: 

Reverting changes in svn is a local operation which shouldn't go to the server at all. So it sounds as though the problem is in your working copy of the project.

Try running 'svn cleanup' in the working copy; you may also want to check if you have problems with the hard drive or filesystem.

Avi
tried clean up - also it happens for other users.
Dan
Are all users sharing a machine? Or it happens on each user's workstation?
Avi
A: 

I have some projects which use the Eclipse IDE. If you capture the Eclipse project directories you get hundreds and hundreds of tiny files which has the same effect for my project as you're suffering on yours.

I think that when you check files out SVN does so one at a time which means that projects with huge numbers of files are always going to be slow and there's not much you can do about it (aside from avoiding frequent whole-repository operations).

Making changes to a single file shouldn't be slow though.

Have you tried the suggestions in another post on stack overflow about slow SVN? Are you using a BDB database?

Jon Cage
It can't have anything to do with the database backend, because reverting a file is a local-only operation. SVN doesn't check out files one at a time either, instead it operates on trees of files.
Sander Rijken
+4  A: 

SVN is slow if you use NFS (Network File System) for the working copy. Could this be your problem?

+21  A: 

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)

Sander Rijken
+9  A: 

There is a known issue with the use of the recycle bin with revert which causes slow reverting. Emptying your recycle bin and setting tortoise not to use it during revert operations both speed up this operation (see http://www.nabble.com/Revert-is-too-slow-td18222196.html).

This has definitely sped up my revert operations.

I had the same issue several times and in my experience it's been the Recycle Bin that's been the culprit.
Josh Kodroff
Recycle bin can't have an effect on checkout performance though
Sander Rijken