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

Posted 2023-03-30

【中文标题】单个大型 SVN 项目的最佳实践

【英文标题】：Best practices for a single large SVN project

【发布时间】：2009-04-14 20:53:37

【问题描述】：

我在 svn 中继承了一个项目：超过 300 000 个文件中的 30Gb。那里有大量的二进制文件，大部分位于图像文件夹中。更新整个项目之类的操作可能会非常缓慢。

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

我个人的解决方案是每天早上 5 点的小型 bash 签出/构建脚本，但不是每个人都有命令行勇气甚至复制我的解决方案，而是宁愿舒适地使用 tortoise svn 和破碎的过程。

有没有人尝试过调整这么大的存储库并可以提供建议？ 是否有任何我可以实施的最佳实践来处理大型存储库，我可以让每个人都轻松进入？

附： externals 似乎不是一个好主意，SVN optimizations to keep large repositories responsive 在这里不适用，因为我正在处理一个项目

附言这目前也在调查中：http://www.ibm.com/developerworks/java/library/j-svnbins.html

【问题讨论】：

有关于这个问题的消息吗？我在我们的项目中遇到了类似的问题。

【参考方案1】：

首先，在客户端和服务器上升级到 SVN 1.6。 latest release 注释提到了大文件的加速 (r36389)。

其次，如果您必须在工作副本中包含整个项目，这可能不太适合您，但请使用sparse directories。我们为我们的大型 repo 执行此操作，客户端所做的第一件事是仅签出***目录，然后为了获取更多数据，使用 repo 浏览器转到所需的目录并在其上“更新到此修订版”。它在 TortoiseSVN 上运行良好。 1.6 还具有“减少深度”选项来删除您不再需要处理的目录。

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

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

最后一个选项 - 关闭 .svn firectories 的病毒扫描程序，以及服务器上的存储库。如果您在服务器上运行 Apache，请确保您在短时间内保持存活（以防止发生重新身份验证）。还要关闭工作副本目录和卷影副本的索引。 （最后一个没有多大帮助，但您可能会看到我所做的更好的改进，在服务器上关闭 AV 将我的 SVN 响应提高了 10 倍）。

【讨论】：

感谢所有建议。我将不得不对它们进行分析，看看哪种效果最好。

@Talesh - 你是如何描述的？ ***.com/questions/2684893/is-there-an-svn-benchmark

【参考方案2】：

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

我们还有一个我们称之为“每日更新”的 Ruby 脚本，已检查到我们的存储库中，我们每天一大早通过 Windows 计划任务在所有开发 PC 上启动该脚本。它将两个结帐更新到最新版本，然后在本地构建所有内容，所以我们一到早上就准备好了。

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

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

【参考方案3】：

为了处理笨重的大小，我会考虑将二进制数据拆分到另一个分支（或者甚至将其完全删除以存储在其他地方），与代码分开。这至少应该会加快速度，尤其是在数据不经常更改的情况下。

我理解人们需要为他们的工具、数据和库提供一个中心位置，但只有一个转储并不好用。

【参考方案4】：

我会保持简短：

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

【参考方案5】：

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

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

【讨论】：

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

抱歉，没有回答这个问题。这就是我们所做的，以解决您描述的几乎相同的情况。几周之内，我们很少遇到您描述的情况。

【参考方案6】：

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