一个单一的大型SVN项目的最佳实践

Question

我继承了一个单一的svn项目:300,000多个文件，占用30Gb的存储空间。这里有大量的二进制文件，主要在一个图像文件夹中。像更新整个项目这样的操作可能会非常缓慢。

团队已经发展出一个流程，只在他们正在工作的特定文件夹上运行更新/切换，并最终提交破损的代码，因为“它在我的电脑上可以运行”。任何一个人的工作副本都可能包含过时的代码、已切换的代码和被遗忘-从未提交的代码。此外，几乎不进行分支处理。

我的个人解决方案是每天早上5点使用一个小的bash检出/构建脚本，但并不是每个人都有命令行勇气甚至复制我的解决方案，他们更喜欢tortoise svn和破损的流程。

有人试过调整如此庞大的存储库并可以给出建议吗？ 是否有任何可以实施与大型存储库一起工作的最佳实践，我可以让每个人轻松地采纳？

P.S. 外部资源似乎不是一个好主意，SVN优化以保持大型存储库的响应性在这里不适用，因为我正在处理单一项目。

P.P.S. 目前也正在研究这个： http://www.ibm.com/developerworks/java/library/j-svnbins.html

- Talesh

---

这个问题有什么新进展吗？我们的项目也遇到了类似的问题。 - Lorenzo Boccaccia

Answer 1

首先，需要在客户端和服务器上升级到SVN 1.6。最新版本的更新说明中提到了对于大文件的加速（r36389）。

其次，如果您必须在工作副本中拥有整个项目，则这可能不太适合您，但可以使用稀疏目录。我们在我们的大型代码库中使用它，客户端所做的第一件事就是仅检出顶层目录，然后要获取更多数据，使用repo浏览器进入所需目录并在其上“更新到此版本”。在TortoiseSVN上效果非常好。1.6还具有“减少深度”选项，以删除您不再需要处理的目录。

如果您不需要更新整个工作副本，仍然可以更新其中的某些部分。在Windows操作系统下，当文件数越多时，更新速度会变慢（NTFS似乎对于用于更新的锁定策略特别差。Bert Huijben注意到了这一点并提出了一个解决方案-待1.7版本发布时再推出，但您可以使用他的“快速修复”重建当前代码）。

另一个选择是更改您的文件系统，如果您可以重新格式化，则可以尝试ext2 IFS驱动程序，但我相信您会谨慎对待！

最后一个选项是关闭您的病毒扫描器以针对“.svn”目录和服务器上的存储库进行扫描。如果您在服务器上运行Apache，请确保短时间内保持活动连接（以防止重新认证发生）。还要关闭工作副本目录和影子副本的索引（最后一个帮助不大，但是关闭服务器上的AV可以将我的SVN响应提高10倍）。

- gbjbaanb

---

感谢所有的建议。我将需要对它们进行剖析，以查看哪个功能最佳。 - Talesh

@Talesh - 你是如何进行性能分析的？http://stackoverflow.com/questions/2684893/is-there-an-svn-benchmark - ripper234

Answer 2

我们有两个仓库，一个用于存放代码（经常更改），另一个用于存放二进制数据（非常庞大，不经常更改）。有时这会带来一些麻烦，但在处理代码时速度更快是值得的。

我们还有一个名为“每日更新”的Ruby脚本，已提交到我们的代码仓库中。我们通过Windows计划任务，在每天早上早期启动所有开发PC上的此脚本。它同时更新两个检出到最新版本的仓库，然后在本地构建所有内容，这样我们在早上到达时就立即可以开始工作了。

我们还存在一些问题 - 例如，当自动化测试运行时，它们检出代码和数据之间目前存在滞后，因此当我们提交更改到两个存储库时，CI服务器有时会收到过时的代码和新数据，这会导致测试失败。

当我们向数据存储库提交更改时，我们通常只需告诉其他人他们需要更新（我们都坐在同一个房间里）。否则，我们通常不会手动更新数据；我们只需让每日更新脚本保持数据新鲜即可。

- Joe White

Answer 3

为了处理庞大的数据量，我建议将二进制数据分离到另一个分支中（甚至完全删除并存储在其他地方），与代码分离。这样至少可以加快速度，特别是如果数据不经常更改。

我理解人们需要一个集中位置来管理他们的工具、数据和库，但只有一个垃圾堆并不好用。

- Dana the Sane

Answer 4

简短概括一下：

• 升级到最新版本（1.6.x）。1.5.x也有速度优化。
• 确保所有人都使用与服务器完全对应的TortoiseSVN版本。我们曾经因为随意更新而遇到过奇怪的问题。
• 外部文件夹可以在同一仓库、不同仓库或不同服务器之间使用。所以你可以将二进制文件移到另一个仓库/服务器，并通过外部文件夹链接到它们。
• 重新组织文件夹，使得在进行稀疏检出时仍能保持高效工作。基本上每个人只检出顶层文件夹和子文件夹，然后有选择地“更新到指定版本”需要完整检出的文件夹。
• 创建脚本来导出、构建，然后提交（或提示提交）。我就有这样的脚本供自己使用。在提交之前，我会运行这个脚本来导出我的wc，然后再构建。请注意：这将复制整个wc！因此，这在数据大小较小的稀疏检出中非常有用。
• 考虑将二进制文件从仓库中移除（我不推荐这么做，但这可能是提高生产力的最明智的解决方案）。
• 记住，导出不创建wc，这意味着与检出相比可以节省50%的磁盘空间。因此，如果你重新组织文件夹，使得二进制文件和不经常更新的项目可以导出而不是检出，就会鼓励更多人“获取全部内容”，而不是尝试快速浏览一些内容。

- Ash

Answer 5

我曾经是一个类似情况下的SCM经理。我们有一个项目，其中包含超过200K个文件（大多数是代码），也遇到了一些相同的问题。我们的解决方案是将存储库分成两个版本。一个版本是开发版本，另一个版本是生产版本。我们用最新和最好的已知工作副本来填充开发版本的代码。开发人员从那里开始进行更改、签入/签出等操作。一旦他们感觉稳定了，管理员（在我们的情况下是构建管理员）就会合并代码并进行测试构建以验证一切是否正常。如果一切都通过了，那就很好。如果没有通过，构建管理员就会追踪开发人员并严厉惩罚他们。在开始时，我们也遇到了一些相同的问题，比如“在我的电脑上可以运行”，但不久之后，这些问题都得到了解决，感谢鞭打和折磨......

在特定的时间点，开发代码（所有工作代码！！！）被合并回生产运行，并发布给客户。

- Mark

---

嗨 Mark，你的答复描述了我们目前的设置和常见的svn模式，但并没有真正回答我的问题。我们的开发人员并没有使用完整的工作副本，因为更新所有内容需要半个小时。 - Talesh

抱歉，没有回答你的问题。不过，这就是我们解决几乎与你描述的情况相同的方法。在几周内，我们很少遇到像你描述的那种情况了。 - Mark

Answer 6

是否有可能将项目分解成较小的项目，并通过某种插件系统进行连接？

- waaaaa