我们最近将代码版本控制系统迁移到 SVN，它一直为我们服务。我们有一个不常见的要求，即我们必须能够在我们的产品面世后的 30 年内运行我们的代码（和测试）工具链。这意味着我们需要归档整个工具链，包括 IDE、编译器、许可服务器和作品。我们天真的方法是使用我们的工具在 SVN 中创建一个文件夹，其中包含版本的子文件夹（因为不同的项目可能使用同一工具的不同版本创建其生产版本）。
然而，在我看来，我们最终将在我们的代码旁边存储数十 GB 或更多价值的这些工具。我发现一些参考资料表明，旧版本的 SVN 在包含大型二进制文件的存储库中存在困难，但这似乎已得到修复。我还没有找到任何关于这种结构的 SVN 性能的最新指标。
除了随着存储库变大而难以备份存储库之外，这种幼稚的方法是否有任何缺点？
到目前为止，我看到的替代方案是： 1. 为构建工具创建一个单独的 SVN 存储库 2. 为构建工具创建一个网络驱动器，并保留它们的校验和的索引，以便将来可以识别它们。
我意识到这可能有点主观，所以我对任何可能可用的客观指标最感兴趣。
简短的回答是——不要。SVN（和其他类似的）是一个源代码版本控制系统，它从来没有被设计用来处理你提到的大型二进制文件。您最好建立一个虚拟环境并将您的工具链和其余部分放在 VM 文件中，并将这些安全的地方以及 VM 主机程序存放在安全的地方。
SVN 确实具有为您提供真正的版本管理和审计跟踪的优势，如果这很重要的话。我会为这些对象创建一个单独的存储库，并仅用于svn import获取内容。您可以使用非常有限的数据子集创建工作副本（如果您需要提取某些内容）。否则，您可以使用 Web 浏览器浏览 repo。在这些限制下，你不应该遇到任何问题——SVN 基本上是作为一个存档系统，上面有版本管理。
我显然不会将 IDE 存储在 SVN 存储库中，因为您不能仅仅将例如 Visual Studio 文件夹复制到某个目录并让它再次运行。您必须在某处存档安装 DVD。但是由于这不会改变，因此您可以为此使用普通的备份位置（磁带、磁盘等）。但问题还在继续：如果下一个操作系统不再支持这个 IDE 怎么办？
因此，我的想法是创建一个虚拟机，在已发布软件的状态下安装并运行所有内容，然后将此映像保存在某处。因为如果您需要在 30 年后运行此程序，首先您可能无法在明天的操作系统上运行今天的安装程序。更好的是，把整台电脑放在安全的地方。并希望它在 30 年后仍然有效。由于您（我猜）不需要能够恢复每个版本，而只需要恢复已发布的版本，因此对我来说，整个事情对 SVN 来说都不是问题。