我们现在对SVN非常满意，但Joel's tutorial引起了我的兴趣。所以我想知道 - 在我们的情况下它是否可行？
事情是 - 我们的SVN存储库是巨大的。该软件本身已有15年的历史，并且已经存在于几个不同的源控制系统中。有超过68,000个修订版（更改集），源本身占用超过100MB，我甚至无法猜测整个存储库消耗了多少GB。
问题很简单 - 整个存储库的克隆可能需要很长时间才能完成，并且会在远程理智的驱动器上消耗更多空间。而且，由于分布式版本控制的重点是拥有所需数量的存储库，我开始怀疑。
Mercurial（或任何其他分布式版本控制）如何处理此问题？或者它们无法用于如此庞大的项目？
添加：为了澄清 - 整个事情是一个项目的整体野兽，它编译成一个单独的.EXE并且不能被拆分。
已添加2：第二个想法 - Linux内核存储库使用git，可能比我的大一个数量级或两个数量级。那么它们如何使它发挥作用呢？
答案 0 :(得分：13)
HUGE项目的分布式版本控制 - 是否可行？
绝对！如你所知，Linux是庞大的并且使用Git。 Mercurial is used for some major projects也是如此，例如Python，Mozilla，OpenSolaris和Java。
我们现在对SVN非常满意，但Joel的教程引起了我的兴趣。所以我想知道 - 在我们的情况下它是否可行？
是。如果你现在对Subversion感到满意，你可能没有做太多的分支和合并！
事情是 - 我们的SVN存储库是巨大的。 [...]有超过68,000个修订版（变更集），源本身占用超过100MB
正如其他人所指出的那样，与许多现有项目相比，这实际上并没有那么大。
问题很简单 - 整个存储库的克隆可能需要很长时间才能完成，并且会在远程理智的驱动器上消耗更多的空间。
Git和Mercurial都非常有效地管理存储，而且它们的存储库占用的空间远远小于等效的Subversion存储库（已经转换了一些）。一旦你有一个初步结账，你只是推动增量，这是非常快。它们在大多数操作中都明显更快。最初的克隆是一次性的成本，所以它花了多长时间并不重要（我打赌你会感到惊讶！）。
由于分布式版本控制的重点是拥有所需数量的存储库，我开始怀疑。
磁盘空间很便宜。开发人员生产力更重要。那么如果回购占用1GB呢？如果你能更聪明地工作，那就值得。
Mercurial（或任何其他分布式版本控制）如何处理此问题？或者它们无法用于如此庞大的项目？
可能值得一读的是Mozilla等projects using Mercurial如何管理转换过程。其中大多数都有多个回购，每个回购都包含主要成分。 Mercurial和Git也都支持嵌套存储库。还有一些工具可以管理转化过程 - Mercurial has built-in support for importing from most other systems。
补充：为了澄清 - 整个事情是一个项目的整体野兽，它编译成一个单独的.EXE，不能拆分。
这使得更容易，因为您只需要一个存储库。
补充2：第二个想法 - Linux内核存储库使用git，可能比我的大一个数量级或两个数量级。那么它们如何使它发挥作用呢？
Git专为原始速度而设计。磁盘格式，有线协议，内存中算法都经过了大量优化。他们已经开发了复杂的工作流程，补丁从单个开发人员，到子系统维护人员，再到中尉，最终到Linus。 DVCS的最大优点之一是它们非常灵活，可以实现各种工作流程。
我建议你阅读Bryan O'Sullivan的excellent book on Mercurial，这会让你快速上手。下载Mercurial并完成示例，并在一些临时回购中使用它来感受它。
然后启动convert命令以导入现有的源存储库。然后尝试进行一些本地更改，提交，分支，查看日志，使用内置Web服务器等。然后将其克隆到另一个框并推动一些更改。计算最常见的操作，并查看它的比较方式。您可以免费进行全面评估，但有些时间。
答案 1 :(得分：11)
100MB的源代码少于Linux内核。 Linux内核2.6.33和2.6.34-rc1之间的更改日志有6604次提交。您的存储库规模对我来说并不令人生畏。
两倍，但仍然是我们都拥有大硬盘的花生。
答案 2 :(得分：3)
不要担心存储库空间要求。我的轶事：当我将我们的代码库从SVN转换为git（完整历史 - 我认为）时，我发现克隆使用的空间比WVN工作目录少。 SVN保留所有签出文件的原始副本：在任何SVN签出中查看$ PWD / .svn / text-base /。使用git，整个历史记录占用的空间更少。
让我感到惊讶的是网络效率git是多么令人惊讶。我在一个连接良好的地方做了一个项目的git克隆，然后把它带回了闪存盘，在那里我用git fetch / git pull保持最新状态，只有我微不足道的小GPRS连接。我不敢在SVN控制的项目中做同样的事情。
你真的欠自己至少尝试一下。我想你会对你的以集中式VCS为中心的假设有多么错误而感到惊讶。
答案 3 :(得分：2)
你需要所有历史吗？如果您只需要过去一两年，可以考虑将当前存储库保留为只读状态以供历史参考。然后通过使用下限修订版svnadmin dump创建一个仅包含最近历史记录的新存储库，这将构成新分布式存储库的基础。
我同意另一个答案，100MB工作副本和68K修订版并不是那么大。试一试。
答案 4 :(得分：2)
你说你对SVN很满意......为什么要改变？
就分布式版本控制系统而言，Linux使用git而Sun使用Mercurial。两者都是令人印象深刻的大型源代码存储库，它们工作正常。是的，您最终会对所有工作站进行所有修订，但这是您为分散化而付出的代价。记住存储很便宜 - 我的开发笔记本电脑目前有1TB（2x500GB）的硬盘存储空间。你有没有测试过将你的SVN repo拉成像Git或Mercurial这样的东西来实际看需要多少空间？
我的问题是 - 你准备好作为一个分散的组织吗？对于软件商店来说，保持中央存储库（定期备份，连接到CruiseControl或FishEye，更容易控制和管理）通常更有意义。
如果您只想要比SVN更快或更具可扩展性的东西，那么只需购买商业产品 - 我使用了Perforce和Rational ClearCase，它们可以毫无问题地扩展到大型项目。
答案 5 :(得分：1)
您将一个巨大的存储库拆分为许多较小的存储库，每个存储库用于旧存储库中的每个模块。通过这种方式，人们可以简单地将其作为存储库保存在以前的SVN项目中。没有比以前更多的空间了。
答案 6 :(得分：1)
我在一个相当大的c＃/ .net项目上使用git（在一个解决方案中有68个项目），并且完整树的新鲜提取的TFS足迹是~500Mb。在本地存储相当数量的提交的git仓库重量约为800Mb。压缩和存储在git内部工作的方式非常好。如此多的变化包含在如此少的空间中，真是太神奇了。
答案 7 :(得分：0)
根据我的经验，Mercurial非常擅长处理大量文件和庞大的历史。缺点是您不应该签入大于10 Mb的文件。我们使用Mercurial来保存已编译DLL的历史记录。不建议将二进制文件放在源控制器中，但我们无论如何都尝试过它（它是专用于二进制文件的存储库）。存储库大约2 Gig，我们不太确定我们将来能够继续这样做。无论如何，对于源代码，我认为你不必担心。
答案 8 :(得分：0)
Git显然可以使用与您一样大的项目，因为您指出，Linux内核本身就更大。
使用Mercurial和Git的挑战（不知道你是否管理大文件）是他们无法管理大文件（到目前为止）。
我有经验将您的规模（大约15年）的项目从CVS / SVN（实际上是两者的混合）转移到塑料SCM中进行分布式和集中化（两个工作流程发生在同一个组织内部）同时）发展。
这一举动永远不会是无缝的，因为它不仅是一个技术问题，而且涉及很多人（一个像你这样大的项目可能涉及几百个开发人员，不是吗？），但有些进口商可以自动迁移和培训也可以很快完成。
答案 9 :(得分：-2)
不，不行。你不希望任何需要在客户端进行重要存储的东西。如果你变得那么大（通过拍摄例如图像等），存储需要的不仅仅是普通的工作站有效。
你最好选择集中的东西。简单的数学 - 在每个工作站上使用gb并且在那里效率很高是不可行的。这根本没有意义。