乌龟 svn 需要多次尝试才能做任何事情
我和我们网站上的大约 20 个其他人一起使用 Tortoise svn，但都遇到了持续的问题。每当您选择任何命令（更新、提交或右键单击菜单的任何项目）时，软件几乎总是最初缺乏响应。 也就是说，它会沙漏几秒钟，然后什么也不做。因此，您重复该请求，但通常仍然不起作用，并且症状相同。它通常会在第三次尝试时起作用，但有时需要第四次，在极少数情况下甚至需要第五次尝试才能让它运行他的命令。第一次可能有 10% 的时间可以工作。
另一个症状是它逐渐建立多个 TortoiseProc.exe 进程（我目前正在运行其中 8 个），其中一些进程保持对某些文件的锁定，因此您必须终止该进程才能重新获得对该文件的完全访问权限。但我不确定这是否是这些问题的结果，因为失败命令的数量和进程数量之间不是“1 对 1”的关系。在典型的一天中，我可能会执行 6 个 Tortoise 命令，但这需要 10 - 12 次尝试才能让它们工作。
一种理论认为 PGP 导致了问题，因为所有数据都存在于已安装的 PGP 驱动器上。但很难理解为什么它需要随机数进行尝试，并且最终总是有效。
这慢慢让我们发疯，任何想法都将不胜感激。
格伦
I use Tortoise svn along with about 20 others at our site and all have an ongoing issue with it. Whenever you choose any command (update, commit, or ANY item of the right-click menu) there is almost always an initial lack of repsonse from the software.
That is, it hourglasses for a few seconds and then does nothing. So you repeat the request, and it quite often still doesn't work, with same symptoms. It will typically work on the 3rd attempt, but sometimes it takes a 4th and on rare occasions even a 5th try to get it to run he command. Maybe 10% of the time it works first time.
The other symptom is that it gradually builds up multiple TortoiseProc.exe processes (I currently have 8 of these running), some of which maintain a lock on certain files so you have to kill the process to regain full access to the file. But I'm not sure if this is a result of these issues or not as it is not a '1 to 1' relationship between the number of failed commands and the number of processes. In a typical day I might execute 6 Tortoise commands, but this will have taken say 10 - 12 attempts to get them to work.
One theory is that PGP is causing issues, as all data exists on mounted PGP drives. But hard to understand why it takes a random number fo attempts, and always works in the end.
This is slowly driving us all nuts and any thoughts would be appreciated.
Glenn
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
好吧，如果理论上是 PGP 导致了问题，那么您为什么不尝试从未加密的驱动器上尝试，看看是否可以解决问题呢？您的源代码是否非常敏感以至于需要存储在加密驱动器上？
我已经使用 TortoiseSVN 一段时间了，而且我从未遇到过你提到的那种问题，所以听起来确实是你的设置中的某些问题导致了问题。
Well, if the theory is that PGP is causing the issue, why don't you try from a drive that isn't encrypted, and see if that fixes the problem? Is your source code so sensitive that it needs to be on an encrypted drive?
I've used TortoiseSVN for a while, and I've never had the sort of problem you're mentioning, so it does sound like something in your setup is causing a problem.
我不确定这是否与您的问题完全相关，但我发现 TortoiseSVN 在处理包含大量文件的存储库时有时会非常慢。这体现在 tsvncache.exe 进程占用大量内存。 tsvncache.exe 进程扫描文件和文件夹，并将熟悉的图标与它们相关联以表示已更改/忽略的等文件。
解决此问题的方法是告诉 Tortoise SVN 仅缓存您正在使用的文件夹并忽略其他文件夹。为此，右键单击您的项目文件夹并选择 TortoiseSVN->设置->图标叠加。我将排除路径设置为 c:\* 和 d:\* （基本上忽略所有固定驱动器）并将包含路径设置为我的项目文件夹。
I'm not sure if this is exactly related to your issue but I have found TortoiseSVN can sometimes be quite slow when dealing with repositories that have a lot of files in them. This manifests itself in the tsvncache.exe process taking up a lot of memory. The tsvncache.exe process scans files and folders and associates the familiar icons with them to denote changed/ignored etc. files.
A fix for this is to tell Tortoise SVN to only cache the folders you are working in and ignore the others. To do this, right-click your project folder and select TortoiseSVN->Settings->Icon Overlays. I have Exclude paths set to c:\* and d:\* (basically ignore all fixed drives) and Include paths set to my projects folder.
我会尝试将客户端排除在外，这样您就可以确定它是否确实是乌龟的问题，或者根本原因是在服务器上。为什么不尝试直接从 PC 使用 Subversion 命令行来执行 Tortoise 执行效果较差的功能呢？如果可以的话，您可能还想尝试直接在服务器上运行 Tortoise，以排除网络的影响。继续尝试删除可能导致问题的变量，您将很快将问题范围缩小到根本原因。
I’d be trying to take the client out of the picture so you can establish whether it is indeed a Tortoise a problem or the root cause is at the server. Why don’t you try just using the Subversion command line directly from your PC to perform functions which are performing poorly with Tortoise? If this is ok, you might also want to try running Tortoise directly on the server to take the network out of the equation. Keep trying to remove the variables which could be causing the problem and you’ll narrow it down to a root cause pretty quickly.