svn - 大型项目的分布式版本控制 - 可行吗？

Question

我们现在对 SVN 很满意，但是 Joel's tutorial引起了我的兴趣。所以我想知道 - 在我们的情况下也可行吗？

问题是 - 我们的 SVN 存储库很大。该软件本身已有 15 年的历史，并且已经在几个不同的源代码控制系统中幸存下来。有超过 68,000 次修订(变更集)，源本身占用超过 100MB，我什至无法猜测整个存储库消耗了多少 GB。

那么问题很简单 - 整个存储库的克隆可能需要很长时间才能完成，并且会在远程正常的驱动器上消耗更多空间。由于分布式版本控制的重点是根据需要拥有尽可能多的存储库，因此我开始怀疑。

Mercurial(或任何其他分布式版本控制)如何处理这个问题？或者它们无法用于如此庞大的项目？

补充:澄清一下 - 整个事情是一个项目的一个整体野兽，它编译为单个 .EXE 并且无法拆分。

添加 2:第二个想法 - Linux 内核存储库使用 git，可能比我的大一两个数量级。那么他们是如何让它发挥作用的呢？

Answer 1

100MB 的源代码小于 Linux 内核。 Linux 内核 2.6.33 和 2.6.34-rc1 之间的更新日志有 6604 次提交。你的存储库规模对我来说并不可怕。

从 .tar.bz2 存档解压缩的 Linux 内核 2.6.34-rc1:445MB

从主 Linus 树 check out 的 Linux 内核 2.6 头:827MB

两倍，但仍然与我们都有的大硬盘驱动器有关。