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

Question

我在svn：30Gb中继承了超过300,000个文件中的单个项目。大量的二进制文件主要存在于图像文件夹中。更新整个项目等操作可能会非常缓慢。

该团队已经发展了一个流程，只对他们正在处理的特定文件夹运行更新/切换，并最终检查损坏的代码，因为“它可以在我的计算机上运行”。任何一个人的工作副本都可以包含过时的代码，切换的代码和遗忘 - 从未提交过的代码。此外，还会发生最小的分支。

我的个人解决方案是每天早上5点发布一个小的bash checkout / build脚本，但并不是每个人都有命令行勇敢甚至复制我的解决方案，宁愿选择简单的乌龟svn和破碎的过程。

是否有人试图调整这么大的存储库并提供建议？ 我是否可以使用最佳实践来处理大型存储库，以便让每个人都能轻松应对？

P.S。外部似乎不是一个好主意，SVN optimizations to keep large repositories responsive不适用于此，因为我正在处理一个项目

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

Answer 1

首先，在客户端和服务器上升级到SVN 1.6。 latest release笔记提到了大文件的加速（r36389）。

其次，如果您必须在工作副本中包含整个项目，但使用sparse directories，这可能不适合您。我们为大型仓库执行此操作，客户端所做的第一件事就是仅检查顶级目录，然后获取更多数据，使用repo浏览器转到所需目录并在其上“更新到此版本”。它在TortoiseSVN上运行得非常好。 1.6还有'reduce depth'选项来删除不再需要处理的目录。

如果这不适合您，您仍然可以对部分工作副本进行更新。你拥有的文件越多，更新速度就越慢（在Windows上，使用用于更新的锁定策略，NTFS似乎特别差。Bert Huijben noticed this并建议修复 - 使用1.7版本的TBA，但你可以重建你的当前代码是他的'快速修复'。

另一种方法是更改​​文件系统，如果你可以重新格式化，你可以试试ext2 IFS driver，但我相信你会对此保持谨慎！

上一个选项 - 关闭.svn firectories的病毒扫描程序，以及服务器上的存储库。如果您在服务器上运行Apache，请确保您在短时间内保持活动状态（以防止重新进行身份验证）。同时关闭工作副本目录和卷影副本的索引。 （最后一点没什么用，但你可能会看到我做的更好的改进，在服务器上关闭AV会提升我的SVN响应10倍）。

Answer 2

我们有两个存储库，一个用于我们的代码（经常更改），另一个用于我们的二进制数据（非常大，不经常更改）。有时这很痛苦，但在使用代码时值得提高速度。

我们还有一个Ruby脚本，我们称之为“每日更新”，检查到我们的存储库，我们每天早上通过Windows计划任务启动所有开发PC。它将结账更新到最新版本，然后在本地构建所有内容，因此我们准备在早上到达时立即开始。

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

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

Answer 3

为了处理笨重的大小，我会考虑将二进制数据拆分成另一个分支（甚至完全删除它以存储在别处），与代码分开。这至少应该加快速度，特别是如果数据不经常变化的话。

我理解人们需要为他们的工具，数据和库提供一个中心位置，但是只有一次转储才能正常工作。

Answer 4

我会简短地说明一下：

• 升级到最新版本（1.6.x）。 1.5.x也有速度优化。
• 确保每个人都使用相同版本的TortoiseSVN，它是根据服务器的确切版本构建的。我们遇到很多问题，他们随心所欲地更新，然后遇到奇怪的问题。
• 外部在同一个repo上的服务器，存储库和文件夹之间工作。所以你可以将二进制文件一起移动到另一个repo / server，只需用外部链接链接到它们。
• 重新构建文件夹，以便您可以稀疏结帐项目，并且仍然可以高效地工作。基本上每个人都会检查tops文件夹+子项，然后选择性地“更新到修订版”他们需要完全结账的文件夹。
• 创建导出，构建然后提交（或提示提交）的脚本。我有这样的脚本供我使用。在提交之前，我运行脚本并导出我的wc然后构建。注意：这将复制完整的wc！因此，这对于数据大小较小的稀疏检出非常有用（呃）。
• 考虑将二进制文件移出repo（我不建议这样做，但它可能是提高工作效率的最佳解决方案）。
• 请记住，导出不会创建wc，这意味着与结帐相比，您可以节省50％的磁盘空间。因此，如果您进行重组，以便可以导出二进制文件和不经常更新的项目而不是结帐，这将鼓励更多人“完成整个事情”，而不是尝试浏览其中的一些。

Answer 5

在类似的情况下我是SCM经理。我们有一个超过200K文件（主要是代码）的项目，它有一些相同的问题。我们的解决方案是将存储库拆分为两个版本。一个版本是开发版本，另一个版本是生产版本。我们在开发版本中播放了所有代码的最新且最着名的工作副本。开发人员开始使用它并进行更改，签入/签出等等。一旦他们觉得事情稳定，管理员（在我们的例子中是构建管理器）合并代码并进行测试构建以验证一切正常。如果一切都通过它是好的。如果没有，构建管理员会追捕开发人员并严厉惩罚他们。我们在开头有一些相同的问题，“它在我的电脑上工作”等等，但不久之后，由于殴打和鞭打而得到了解决......

在特定点，开发代码（ALL WORKING CODE !!!!）被合并回生产运行并发布给客户。

Answer 6

是否有可能将项目分解为可以通过某种插件系统连接的较小项目？