转到git时，如何处理大型svn历史记录？
编辑：与某些类似的问题不同，例如将多GB SVN存储库移至Git 或 /programming/540535/managing-large-binary-files-with-git 我的方案不涉及几个子项目可以很容易地转换为git子模块，也不能转换为一些非常适合git-annex的非常大的二进制文件。它是一个单一的存储库，其中的二进制文件是测试套件，与相同修订版的主要源代码紧密耦合，就像它们是编译时资产（例如图形）一样。 我正在研究从svn切换旧的中型/大型（50个用户，60k修订，80Gb历史记录，2Gb工作副本）代码存储库。随着用户数量的增加，主干中流失很多，并且功能通常分散在多个提交上，这使得代码审查变得困难。同样，如果没有分支，就无法“排除”不良代码，只有在提交到主干后才能进行检查。我正在研究替代方案。我希望我们可以转到git，但遇到一些问题。 就git而言，当前仓库的问题是大小。那里有很多旧文件，转换为git时用--filter-branch清理它可以将文件大小减小一个数量级，大约为5-10GB。这仍然太大。大型存储库的最大原因是，有很多二进制文档正在输入到测试中。这些文件的大小在.5mb到30mb之间，有数百个。他们也有很多变化。我看过子模块，git-annex等，但是在子模块中进行测试感觉很不对劲，对许多想要完整历史记录的文件都有附件也是如此。 因此，git的分布式特性实际上是阻止我采用它的原因。我并不真正在乎分布式，我只想要便宜的分支和强大的合并功能。就像我假设99.9％的git用户那样，我们将使用一个有福的，裸露的中央存储库。 我不确定我是否理解为什么每个用户在使用git时都要拥有完整的本地历史记录？如果工作流不是分散的，那么该数据在用户磁盘上做什么？我知道在git的最新版本中，您可以使用仅具有最新历史记录的浅表克隆。我的问题是：将其作为整个团队的标准运作模式是否可行？可以将git配置为始终很浅，以便您只能在中央拥有完整的历史记录，但是默认情况下，用户只有1000转的历史记录？当然，可以选择仅将1000 revs转换为git，并保留svn repo用于考古。但是，在这种情况下，在对测试文档进行了数千次修订之后，我们将再次遇到相同的问题。 什么是使用Git含有许多二进制文件，你大回购了良好的最佳实践也希望历史？大多数最佳实践和教程似乎都避免了这种情况。他们解决了几个巨大的二进制文件的问题，或建议完全删除二进制文件。 浅克隆是否可作为正常操作模式使用？还是“骇客”？ 子模块是否可以用于在主源版本和子模块版本之间具有严格依赖性的代码（例如，在编译时二进制依赖性或单元测试套件中）？ git存储库（在内部）的“太大”是多少？如果可以将其降低到4GB，我们应该避免切换吗？2GB？