SVN/TortoiseSVN painfully slow

Question

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?

Spree

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

dude this is NOT normal, not even close to what normal svn speeds are. You should be questioning who's managing your svn server/repos and what the hell that server is running. Does it have 1 gig ram or something sickling? No clue why the answer states that what you've detailed us is normal because it's not. Only in poorly run dev teams or lack of maintenance of your svn repo is the cause. It is not acceptable. – Spireme

If it helps s.o. looking for a simular issue: my setup was very painfull slow as well: win7, eclipse, visualsvn. After changing the JavaHL to the native Win-implementation it was lightspeed rocket fast. – Leet

Answer 1

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)

Hamhung

I don't get it. I have worked with Tortoise SVN for 3-4 companies and never have I seen it this slow and we had projects that were 1 gb! I am shocked that I'm seeing threads like these now that I'm at a new company and it's taking me hours to download a 300mb .NET project. – Spireme

Yet another company where it's slow...wtf v1.6 but I've seen v1.6 be much faster than this at other companies. – Spireme

Four years on from the most recent comment and guess what? SVN is still painfully slow. I work with a large project of about 2-3GB and many, many directories. I've just resigned to the fact that I can't do a "commit" or "update" on the entire project. It has to be done in chunks- roughly I have to divide into about 10 sub folders. Update I can sometimes get away with, because I guess it doesn't grab so many locks. – Cupp

It must just depend on the structure of the project and numbers of tiny files. Where I work we have projects upwards of 17 GB and they update / commit fine. :/ – They

Persuade your company to migrate to Git for god's sake – Armenian

Answer 2

There is a known issue with the use of the recycle bin with revert which causes slow reverting. Emptying your recycle bin and setting TortoiseSVN 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.

Georas

I had the same issue several times and in my experience it's been the Recycle Bin that's been the culprit. – Enfilade

Recycle bin can't have an effect on checkout performance though – Hamhung

I'm on TortoiseSVN 1.7.6 and revert remains painfully slow, but my recycle bin is slow - I always use shift-delete to delete without recycling. I just changed Tortoise to deactivate: Settings Dialog->Dialogs 1->"Use recycle bin when reverting". I'll bet it will help! Thank you! – Grau

The link is (effectively) broken. It redirects to the home page, nabble.com. – Gaucherie

Answer 3

I experienced extreme slowness with Subversion on Windows after changing my password. I had to delete all directories and files from %APPDATA%\Subversion\auth.

Now SVN is fast as a hare. My slowness occurred via both TortoiseSVN and the command line.

Trace

Same problem in my case, removing "auth" folder really helps. – Capriola

This really saved my day. – Calistacalisthenics

For me on windows 10 it was at C:\Users\UserName\AppData\Roaming\Subversion\auth – Petulancy

%APPDATA% normally expands to "C:\Users\UserName\AppData\Roaming" – Mccool

Answer 4

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

Paley

@ChrisKL: And Windows supports NFS. – Speer

Answer 5

We have face similar issue, the problem was TortoiseSvn (Version 1.9.7). For example, the repo browser took about 10 minutes to initial.

We have turned of the Show Locks feature and every thing fixed!

Right click on a folder and select Tortoise\Settings then General\Dialog 3 then deselect Show Locks

Also some good hints can be found at http://tigris-scm.10930.n7.nabble.com/Workaround-for-slow-RepositoryBrowser-on-large-repositories-td92324.html

Petulancy

Answer 6

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.

Justin

Are all users sharing a machine? Or it happens on each user's workstation? – Justin

Answer 7

Our SVN was running painfully slow through TortoiseSVN, Eclipse and command line. Commits and exports were slow. Our Zend Framework-based PHP projects would take an age to update and popping in a small commit of about three files would take 5-10 minutes.

Our SVN virtual machine (CentOS) only had 700 MB of RAM which seemed reasonable for a Linux CLI only running Subversion via Apache and has been running fine for about one year. We've only got about 20 projects and only three developers.

I've upped it to 1.5 GB of RAM and things are running much faster now, back to our old speeds.

Spindell

Answer 8

I also suffered a large slowdown after upgrading to TortoiseSVN 1.7.3.

Then I discovered I had a separate install of SVN 1.6.5. I uninstalled both and reinstalled TortoiseSVN and now things are much better. First update of the day in TortoiseSVN is still slow (1-2 minutes), but fast after that.

Dasi

Answer 9

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.

You may try the suggestions in another post on Stack Overflow about slow SVN. It could also be due to using a BDB database.

Words

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. – Hamhung