blocks|key|1324538|text|恢复SVN中的更改是一个本地操作，根本不应该转到服务器。因此，听起来好像问题出在项目的工作副本中。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1324539|尝试在工作副本中运行“svn+cleanup”；您可能还希望检查硬盘或文件系统是否有问题。|1324540|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

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.

blocks|key|1324570|text|我有一些使用Eclipse+IDE的项目。如果您捕获Eclipse项目目录，您将获得成百上千个小文件，这对我的项目的影响与您自己的项目的影响相同。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1324571|我认为当你签出文件时，SVN一次签出一个文件，这意味着拥有大量文件的项目总是会很慢，你对此无能为力(除了避免频繁的整个存储库操作)。|1324572|不过，对单个文件进行更改应该不会太慢。|1324573|您可以尝试another+post+on+Stack+Overflow+about+slow+SVN中的建议。这也可能是由于using+a+BDB+database造成的。|offset|length|1324574|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/65135/how-can-i-speed-up-svn-updates|1|https://en.wikipedia.org/wiki/Apache_Subversion#Berkeley_DB_.28deprecated.5B16.5D.29^0|0|0|0|5|19|0|1Q|K|1|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|U|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|V|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|W|8|@]|9|@$H|X|I|Y|1|Z]|$H|10|I|11|1|12]]|A|$]]|$1|J|3|-4|5|6|7|13|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]|R|$5|M|N|O|A|$P|S]]]]

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 <a href="https://stackoverflow.com/questions/65135/how-can-i-speed-up-svn-updates">another post on Stack Overflow about slow SVN</a>. It could also be due to <a href="https://en.wikipedia.org/wiki/Apache_Subversion#Berkeley_DB_.28deprecated.5B16.5D.29" rel="nofollow noreferrer">using a BDB database</a>.

blocks|key|1539754|text|如果您使用NFS+(Network+File+System)作为工作副本，SVN就会很慢。这可能是你的问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1539755|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Network_File_System_%2528protocol%2529^0|A|J|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

SVN is slow if you use NFS (<a href="http://en.wikipedia.org/wiki/Network_File_System_%28protocol%29" rel="nofollow noreferrer">Network File System</a>) for the working copy. This could be your problem.

blocks|key|1539792|text|当有大量的目录时，Subversion工作副本的性能非常差，就像您的例子一样。对于对工作副本的写操作(即使是本地的)，工作副本必须被锁定，这意味着在每个目录(即创建的11k文件)中创建一个锁定文件，然后执行该操作，并再次删除这些11k文件。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1539793|Subversion+1.7正在转移到不同的工作副本格式，这应该可以解决这些问题。在此之前，您可能会尝试一些技巧来加快速度，比如从病毒扫描程序中排除工作副本，禁用目录上的文件监视器(如TortoiseSvnCache)，以及尝试减少目录的总数。(也许可以检出几个单独的工作副本)|1539794|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

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)

blocks|key|1539825|text|回收站与revert的使用存在一个已知问题，它会导致恢复缓慢。清空回收站并将TortoiseSVN设置为在还原操作期间不使用回收站都会加快此操作的速度(请参见http://www.nabble.com/Revert-is-too-slow-td18222196.html)。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1539826|这无疑加快了我的还原操作。|1539827|entityMap|0|LINK|mutability|MUTABLE|url|http://www.nabble.com/Revert-is-too-slow-td18222196.html^0|27|1K|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

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 <a href="http://www.nabble.com/Revert-is-too-slow-td18222196.html" rel="nofollow noreferrer">http://www.nabble.com/Revert-is-too-slow-td18222196.html</a>). 

This has definitely sped up my revert operations.

blocks|key|1539852|text|在更改密码后，我在Windows上体验到Subversion的速度非常慢。我不得不从%25APPDATA%25\Subversion\auth中删除所有目录和文件。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1539853|现在SVN像野兔一样快。我的速度缓慢是通过TortoiseSVN和命令行来实现的。|1539854|entityMap^0|16|P|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|M|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|N|8|@]|D|@]|E|$]]]|I|$]]

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

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

blocks|key|1324760|text|我们的SVN通过TortoiseSVN、Eclipse和命令行运行得非常慢。提交和导出都很慢。我们的Zend+Framework-based+PHP项目需要一段时间才能更新，并且在大约三个文件的小提交中弹出将需要5-10分钟。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1324761|我们的SVN虚拟机(CentOS)只有700MB内存，对于只通过Apache运行Subversion的Linux+CLI来说，这似乎是合理的，并且已经运行了大约一年。我们只有大约20个项目和3个开发人员。|1324762|我把它的内存提升到了1.5+GB，现在运行速度快多了，恢复到了原来的速度。|1324763|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Eclipse_%2528software%2529|1|http://en.wikipedia.org/wiki/Zend_Framework|2|http://en.wikipedia.org/wiki/CentOS|3|http://en.wikipedia.org/wiki/Apache_HTTP_Server^0|K|7|0|1E|E|1|0|A|6|2|W|6|3|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@$A|W|B|X|1|Y]|$A|Z|B|10|1|11]]|C|$]]|$1|D|3|E|5|6|7|12|8|@]|9|@$A|13|B|14|1|15]|$A|16|B|17|1|18]]|C|$]]|$1|F|3|G|5|6|7|19|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|1A|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]|P|$5|K|L|M|C|$N|Q]]|R|$5|K|L|M|C|$N|S]]|T|$5|K|L|M|C|$N|U]]]]

Our SVN was running painfully slow through TortoiseSVN, <a href="http://en.wikipedia.org/wiki/Eclipse_%28software%29" rel="nofollow noreferrer">Eclipse</a> and command line. Commits and exports were slow. Our <a href="http://en.wikipedia.org/wiki/Zend_Framework" rel="nofollow noreferrer">Zend Framework</a>-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 (<a href="http://en.wikipedia.org/wiki/CentOS" rel="nofollow noreferrer">CentOS</a>) only had 700 MB of RAM which seemed reasonable for a Linux CLI only running Subversion via <a href="http://en.wikipedia.org/wiki/Apache_HTTP_Server" rel="nofollow noreferrer">Apache</a> 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.

blocks|key|1324814|text|在升级到TortoiseSVN+1.7.3之后，我也遇到了很大的速度减慢。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1324815|然后我发现我有一个单独的SVN+1.6.5安装。我卸载了这两个系统，然后重新安装了TortoiseSVN，现在情况好多了。TortoiseSVN当天的第一次更新仍然很慢(1-2分钟)，但之后更新速度很快。|1324816|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

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.

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&nbsp;KB). Or about 40-60 minutes to check out the project of 100&nbsp;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 <a href="http://www.magentocommerce.com/" rel="noreferrer">Magento</a> 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?

SVN/TortoiseSVN painfully slow

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我在使用我们的一个SVN存储库/项目时遇到了极其缓慢的操作。例如，恢复一个小文件(10KB)中的更改需要5-10分钟。或者大约40-60分钟来检查100兆字节的项目。在同一台服务器上还有大约30个其他项目，有些项目比这个项目大得多，而且没有一个项目像这样预成型。有一件事需要注意，这个项目是一个项目。它的磁盘空间不是很大...

问SVN/TortoiseSVN慢得让人痛苦
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问SVN/TortoiseSVN慢得让人痛苦EN