SVN/TortoiseSVN 非常缓慢答案

【问题标题】：SVN/TortoiseSVN painfully slowSVN/TortoiseSVN 非常缓慢
【发布时间】：2010-10-31 06:33:37
【问题描述】：

我在使用我们的 SVN 存储库/项目之一时遇到了令人痛苦的缓慢操作。

例如，还原一个小文件 (10 KB) 中的更改需要 5-10 分钟。或者大约 40-60 分钟来检查 100 MB 的项目。

在同一台服务器上还有大约 30 个其他项目，其中一些比这个大得多，而且没有一个是这样的。

需要注意的是，这个项目是一个Magento 项目。它的磁盘空间不是很大，但我有 23k 文件和 11k 文件夹，当有很多小文件时，我读得很糟糕；这是真的？我可以做些什么来加快速度吗？

【问题讨论】：

您在服务器上使用什么存储库格式？ FS？开发银行？你可以试试其他的吗？
伙计，这不正常，甚至不接近正常的 svn 速度。您应该质疑谁在管理您的 svn 服务器/存储库以及该服务器到底在运行什么。它有 1 gig ram 还是镰状的东西？不知道为什么答案说您向我们详细说明的内容是正常的，因为事实并非如此。只有在运行不佳的开发团队或缺乏对您的 svn 存储库的维护中才是原因。这是不可接受的。
如果有帮助的话寻找一个类似的问题：我的设置也非常缓慢：win7、eclipse、visualsvn。将 JavaHL 更改为本机 Win 实现后，速度非常快。

标签： magento svn tortoisesvn project revert

【解决方案1】：

在 SVN 中恢复更改是一个本地操作，根本不应该转到服务器。所以听起来好像问题出在您的项目工作副本中。

尝试在工作副本中运行“svn cleanup”；您可能还想检查硬盘驱动器或文件系统是否有问题。

【讨论】：

所有用户都共享一台机器吗？还是发生在每个用户的工作站上？

【解决方案2】：

我有一些使用 Eclipse IDE 的项目。如果您捕获 Eclipse 项目目录，您将获得成百上千个小文件，这些小文件对我的项目的影响与您对您的项目的影响相同。

我认为，当您检查文件时，SVN 一次只检查一个，这意味着具有大量文件的项目总是会很慢，而且您无能为力（除了避免频繁使用整个存储库操作）。

不过，对单个文件进行更改应该不会很慢。

您可以尝试another post on Stack Overflow about slow SVN 中的建议。也可能是因为using a BDB database。

【讨论】：

它与数据库后端没有任何关系，因为恢复文件是仅限本地操作。 SVN 也不会一次检出一个文件，而是对文件树进行操作。

【解决方案3】：

如果您使用 NFS (Network File System) 作为工作副本，SVN 会很慢。这可能是你的问题。

【讨论】：

@ChrisKL：Windows 支持 NFS。

【解决方案4】：

当有大量目录时，Subversion 工作副本的性能很差，就像你的情况一样。对于对工作副本的写操作（甚至仅在本地），必须锁定工作副本，这意味着在每个目录中创建一个锁定文件（即创建 11k 文件），然后执行操作，而这 11k 文件是又删了。

Subversion 1.7 正在转向一种不同的工作副本格式，应该可以解决这些问题。在此之前，您可能会尝试一些技巧来加快速度，例如从病毒扫描程序中排除工作副本，禁用目录上的文件监视器（如 TortoiseSvnCache），并尝试减少目录的总数。（也许通过检查几个单独的工作副本）

【讨论】：

我不明白。我曾与 Tortoise SVN 合作过 3-4 家公司，我从来没有见过这么慢的，我们有 1 GB 的项目！我很震惊，现在我在一家新公司看到这样的线程，而且我需要几个小时才能下载一个 300mb 的 .NET 项目。
又是一家速度很慢的公司...wtf v1.6，但我看到其他公司的 v1.6 比这快得多。
最近的评论已经过去了四年，你猜怎么着？ SVN 仍然非常缓慢。我处理一个大约 2-3GB 的大型项目和很多很多目录。我刚刚接受了我不能对整个项目进行“提交”或“更新”的事实。它必须分块完成——大约我必须分成大约 10 个子文件夹。更新有时我可以侥幸逃脱，因为我猜它不会抓住这么多锁。
它必须只取决于项目的结构和小文件的数量。在我工作的地方，我们有超过 17 GB 的项目，并且它们可以正常更新/提交。 ://
看在上帝的份上说服你的公司迁移到 Git

【解决方案5】：

使用带有 revert 的回收站存在一个已知问题，这会导致恢复缓慢。清空回收站并设置 TortoiseSVN 在还原操作期间不使用它都可以加快此操作（请参阅http://www.nabble.com/Revert-is-too-slow-td18222196.html）。

这无疑加快了我的还原操作。

【讨论】：

我多次遇到同样的问题，根据我的经验，罪魁祸首是回收站。
虽然回收站对结账性能没有影响
我在 TortoiseSVN 1.7.6 上并且恢复仍然非常缓慢，但我的回收站很慢 - 我总是使用 shift-delete 删除而不回收。我只是将 Tortoise 更改为停用：设置对话框->对话框 1->“还原时使用回收站”。我敢打赌它会有所帮助！谢谢！
链接（实际上）已损坏。它重定向到主页，nabble.com。

【解决方案6】：

更改密码后，我在 Windows 上使用 Subversion 时遇到了极其缓慢的情况。我不得不从%APPDATA%\Subversion\auth 中删除所有目录和文件。

现在 SVN 快得像兔子一样。我的缓慢是通过 TortoiseSVN 和命令行发生的。

【讨论】：

在我的情况下同样的问题，删除“auth”文件夹真的很有帮助。
这真的拯救了我的一天。
对我来说，在 Windows 10 上它位于 C:\Users\UserName\AppData\Roaming\Subversion\auth
%APPDATA% 通常扩展为“C:\Users\UserName\AppData\Roaming”

【解决方案7】：

我们的 SVN 通过 TortoiseSVN、Eclipse 和命令行运行缓慢。承诺和出口缓慢。我们基于Zend Framework 的 PHP 项目需要很长时间才能更新，并且弹出大约三个文件的小提交需要 5-10 分钟。

我们的 SVN 虚拟机 (CentOS) 只有 700 MB 的 RAM，这对于仅通过 Apache 运行 Subversion 的 Linux CLI 来说似乎是合理的，并且已经运行了大约一年。我们只有大约 20 个项目，只有三个开发人员。

我已将它提升到 1.5 GB 的 RAM，现在运行速度要快得多，回到我们原来的速度。

【讨论】：

【解决方案8】：

升级到 TortoiseSVN 1.7.3 后，我的速度也大幅下降。

然后我发现我单独安装了 SVN 1.6.5。我卸载了两者并重新安装了 TortoiseSVN，现在情况好多了。 TortoiseSVN 当天的第一次更新仍然很慢（1-2 分钟），但之后很快。

【讨论】：

【解决方案9】：

我们也遇到过类似的问题，问题是 TortoiseSvn（版本 1.9.7）。例如，repo browser 需要大约 10 分钟才能初始化。

我们已经关闭了Show Locks 功能并修复了所有问题！

右键单击文件夹并选择Tortoise\Settings，然后选择General\Dialog 3，然后取消选择 Show Locks

也可以在http://tigris-scm.10930.n7.nabble.com/Workaround-for-slow-RepositoryBrowser-on-large-repositories-td92324.html找到一些好的提示

【讨论】：