我的 SVN 存储库/项目之一的运行速度极其缓慢。
例如，恢复一个小文件 (10KB) 中的更改需要 5-10 分钟。 或者大约需要 40-60 分钟来查看 100 MB 的项目。
同一台服务器上还有大约 30 个其他项目，其中一些比这个项目大得多，但没有一个项目是这样执行的。
需要注意的一件事是，该项目是一个 Magento 项目。 就磁盘空间而言，它不是很大，但我有23k个文件和11k个文件夹，当有很多小文件时，我读SVN预制件很糟糕； 这是真的？ 我能做些什么来加快速度吗？
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?
发布评论
评论（9）
我们也面临类似的问题，问题是TortoiseSvn（版本1.9.7）。 例如，
repo 浏览器需要大约 10 分钟才能初始化。我们已经关闭了
显示锁功能，所有问题都已修复！右键单击一个文件夹，然后选择
Tortoise\Settings，然后选择General\Dialog 3，然后取消选择显示锁也有一些不错的选择可以在 http://tigris-scm.10930.n7.nabble.com/Workaround-for-slow-RepositoryBrowser-on-large-repositories-td92324.html
We have face similar issue, the problem was TortoiseSvn (Version 1.9.7). For example, the
repo browsertook about 10 minutes to initial.We have turned of the
Show Locksfeature and every thing fixed!Right click on a folder and select
Tortoise\SettingsthenGeneral\Dialog 3then deselectShow LocksAlso some good hints can be found at http://tigris-scm.10930.n7.nabble.com/Workaround-for-slow-RepositoryBrowser-on-large-repositories-td92324.html
更改密码后，我在 Windows 上使用 Subversion 时遇到了极其缓慢的情况。 我必须删除
%APPDATA%\Subversion\auth中的所有目录和文件。现在SVN快如兔子。 我的缓慢是通过 TortoiseSVN 和命令行发生的。
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.
如果您使用 NFS (网络文件系统) 作为工作副本，SVN 会很慢。 这可能是你的问题。
SVN is slow if you use NFS (Network File System) for the working copy. This could be your problem.
当有大量目录时（就像您的情况一样），Subversion 工作副本的性能会很差。 对于对工作副本的写入操作（甚至仅在本地），必须锁定工作副本，这意味着在每个目录中创建一个锁定文件（即创建 11k 个文件），然后执行操作，并且这 11k 个文件将被锁定。又删了。
Subversion 1.7 正在转向不同的工作副本格式，这应该可以解决这些问题。 在此之前，您可能会尝试使用一些技巧来加快速度，例如从病毒扫描程序中排除工作副本、禁用目录上的文件监视器（如 TortoiseSvnCache）以及尝试减少目录总数。 （也许可以查看一些单独的工作副本）
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)
使用带有恢复功能的回收站存在一个已知问题，该问题会导致恢复速度缓慢。 清空回收站并设置 TortoiseSVN 在恢复操作期间不使用它都可以加快此操作的速度（请参阅 http://www.nabble.com/Revert-is-too-slow-td18222196.html）。
这无疑加快了我的恢复操作。
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.
恢复 SVN 中的更改是本地操作，根本不应该访问服务器。 所以听起来问题似乎出在您的项目工作副本中。
尝试在工作副本中运行“svn cleanup”； 您可能还想检查硬盘驱动器或文件系统是否有问题。
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.
我们的 SVN 通过 TortoiseSVN、Eclipse 和命令行运行得非常慢。 承诺和出口缓慢。 我们基于 Zend Framework 的 PHP 项目需要很长时间才能更新并在一次小的提交中弹出大约三个文件需要 5-10 分钟。
我们的 SVN 虚拟机 (CentOS) 只有 700 MB RAM，这对于 Linux CLI 来说似乎是合理的仅通过 Apache 运行 Subversion，并且已经正常运行了大约一年。 我们只有大约 20 个项目和 3 名开发人员。
我已将其内存提升至 1.5 GB，现在运行速度更快，回到了原来的速度。
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.
升级到 TortoiseSVN 1.7.3 后，我的速度也大幅下降。
然后我发现我单独安装了 SVN 1.6.5。 我卸载了两者并重新安装了 TortoiseSVN，现在情况好多了。 TortoiseSVN 当天的第一次更新仍然很慢（1-2 分钟），但之后很快。
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.
我有一些使用 Eclipse IDE 的项目。 如果您捕获 Eclipse 项目目录，您将获得成百上千个小文件，这些文件对我的项目的影响与您在您的项目中所遭受的影响相同。
我认为，当您检出文件时，SVN 一次会执行一个操作，这意味着具有大量文件的项目总是会很慢，而且您对此无能为力（除了避免频繁的整个存储库操作）。
不过，对单个文件进行更改应该不会很慢。
您可以尝试Stack Overflow 上关于慢速 SVN 的另一篇文章中的建议。 也可能是由于使用 BDB 数据库 。
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.