我在 svn 中继承了一个项目：超过 300 000 个文件中的 30Gb。那里有大量的二进制文件，大部分位于图像文件夹中。更新整个项目之类的操作可能会非常缓慢。
该团队已经制定了一个流程，只在他们正在处理的特定文件夹上运行更新/切换，并最终检查损坏的代码，因为“它可以在我的计算机上运行”。任何人的工作副本都可能包含过期代码、切换代码和遗忘-从未提交的代码。此外，发生最少的分支。
我个人的解决方案是每天早上 5 点的小型 bash 签出/构建脚本，但并不是每个人都有命令行勇气甚至复制我的解决方案，而是宁愿舒适地使用 tortoise svn 和破碎的过程。
有没有人尝试过调整这么大的存储库并可以提供建议？是否有任何我可以实施的最佳实践来处理大型存储库，我可以让每个人都轻松进入？
PS 外部似乎不是一个好主意，并且保持大型存储库响应的 SVN 优化在这里不适用，因为我正在处理一个项目
PPS 目前也在调查： http: //www.ibm.com/developerworks/java/library/j-svnbins.html
首先，在客户端和服务器上升级到 SVN 1.6。最新的发行说明提到了大文件的加速 (r36389)。
其次，如果您必须在工作副本中包含整个项目，那么这可能不太适合您，而是使用稀疏目录。我们为我们的大型 repo 执行此操作，客户端所做的第一件事是仅签出顶级目录，然后为了获取更多数据，使用 repo 浏览器转到所需的目录并在其上“更新到此修订版”。它在 TortoiseSVN 上运行良好。1.6 还具有“减少深度”选项来删除您不再需要处理的目录。
如果这不适合您，您仍然可以对工作副本的某些部分进行更新。您拥有的文件越多，更新就越慢（在 Windows 上，NTFS 似乎对用于更新的锁定策略特别差。Bert Huijben 注意到了这一点并提出了一个修复 - 1.7 版本的 TBA，但您可以重建您的当前代码与他的“快速修复”。
另一种方法是更改您的文件系统，如果您可以重新格式化，您可以尝试ext2 IFS 驱动程序，但我相信您会对此保持谨慎！
最后一个选项 - 关闭 .svn firectories 的病毒扫描程序，以及服务器上的存储库。如果您在服务器上运行 Apache，请确保您在短时间内保持存活（以防止发生重新身份验证）。还要关闭工作副本目录和卷影副本的索引。（最后一个没有多大帮助，但你可能会看到我所做的更好的改进，在服务器上关闭 AV 将我的 SVN 响应提高了 10 倍）。
我们有两个存储库，一个用于我们的代码（经常更改），另一个用于我们的二进制数据（非常大，不经常更改）。有时这很痛苦，但在处理代码时值得更快的速度。
我们还有一个我们称之为“每日更新”的 Ruby 脚本，它已检查到我们的存储库中，我们每天一大早就通过 Windows 计划任务在所有开发 PC 上启动它。它将两个结帐更新到最新版本，然后在本地构建所有内容，因此我们一到早上就准备好了。
有一些问题我们还没有解决——例如，当我们的自动化测试运行时，他们检查代码和检查数据之间存在延迟，所以当我们提交对两个存储库的更改时，CI服务器有时会获取旧代码和新数据，导致测试失败。
当我们提交对数据存储库的更改时，我们通常只是告诉其他所有人他们需要更新（我们都坐在同一个房间里）。否则，我们通常不会手动更新数据；我们只是让每日更新脚本保持新鲜。
为了处理笨重的大小，我会考虑将二进制数据拆分到另一个分支（甚至完全将其删除以存储在其他地方），与代码分开。这至少应该加快速度，尤其是在数据不经常更改的情况下。
我理解人们需要为他们的工具、数据和库提供一个中心位置，但是只有一个转储就不能很好地工作。
我会保持简短：
我曾是类似情况的 SCM 经理。我们有一个包含超过 200K 文件（主要是代码）的项目，其中存在一些相同的问题。我们的解决方案是将存储库拆分为两个版本。一个版本是开发版本，另一个是生产版本。我们使用所有代码的最新和最知名的工作副本为开发版本播种。开发人员从那里开始并进行更改、签入/签出等。一旦他们觉得事情稳定了，管理员（在我们的例子中是构建经理）合并代码并进行测试构建以验证一切正常。如果一切都过去了，那就太好了。如果不这样做，构建管理员将追捕开发人员并严厉惩罚他们。一开始我们遇到了一些相同的问题，例如“它在我的电脑上工作”等，
在特定点，开发代码（所有工作代码！！！！！！）被合并回生产运行并发布给客户。
是否可以将项目分解为可以通过某种插件系统连接的较小项目？