十多年来，我们有一个非常大的遗留 CVS 存储库 (66GiB)，并且还在不断增加。现在我们有一些分包公司，需要在一些模块和分支上工作。
我们需要为他们创建一些分支并将这些分支发送给他们。我们还需要不时将他们的更改合并到我们的主要分支中。
我们关心的是：
我们不能绝对给他们整个回购，主要是担心安全。
我们需要向他们发送一些历史信息，而不仅仅是“HEAD”版本的代码。
我们仍在做一些开发工作，所以我们需要不时向他们发送变更集。
GIT 和 Mercurial 是从 CVS 迁移的好选择吗？GIT/Mercurial 能满足我们的需求吗？
编辑：我认为我们实际上需要一个具有多站点功能的集中式修订控制，能够基于部分中央回购创建异地回购。并且可以很容易地在站点之间合并。
使用 Git，您可以使用该git subtree命令“剪切”出您可以提供给分包商的子目录，然后轻松地将他们的更改重新集成到您的主线中。如果需要，您还可以定期向他们提供更新。该git subtree命令最初是一个附加组件，但已被纳入contrib官方 Git 发行版的目录。
可以限制您提供给外部用户的存储库中包含的历史记录数量。
不过，我预计您最关心的将是转向具有如此大的起始存储库的 DVCS。Git 会压缩你的 repo，所以当你完成时它不太可能是 66 GB，但它仍然会相当笨重（可能在 10 GB 左右，取决于你在那里存储的内容）。如果你不认为这是一个问题，那就去吧。
我限制了对 Git 的回答，因为我对 Git 比对 Mercurial 更熟悉。
66 GB 听起来很多。然而，众所周知，CVS 存储数据的效率并不高。Git 肯定会为您工作，但您必须将项目拆分为几个较小的 git 存储库。对于大多数项目，将功能拆分为几个独立的子项目（通常是子目录）并不是很困难。通常，您希望将任何给定 git 存储库的大小限制为平均小于 1-2 GB，当然它不应超过 5-10 GB。但是，请记住，git 非常擅长压缩其元数据（只要您git gc偶尔运行一次）。
现在，一旦您将项目拆分为几个子项目（“很少”是相对术语 - Android 有 300 多个），您需要找到一种方法如何将它们再次“粘合”到连贯的目录结构中。
为此，有两种常见的方法：
repoAndroid项目开发的工具。它涉及创建仅包含一个 XML 文件（称为清单）的小型 git 存储库，该文件跟踪您的子项目签入的位置以及它们如何粘合在一起。这在 Linux 和 Mac 上运行良好，但不幸的是不支持 Windows（repo需要操作系统的符号链接支持）。git submodule's。创建一个没有任何真实文件的 git 存储库，并将所有原始子项目作为子模块添加到该存储库中。从某种意义上说，这个超级git repo 与 Android repo manifest 的作用基本相同。这种方法的优点是它受到任何操作系统的支持，包括 Windows。现在，如果您只想共享庞大项目的一小部分，您可以通过将任何子模块/子项目作为标准 git 存储库直接共享给您的合作伙伴来实现。
事实上，为了更方便，我强烈建议安装Gerrit - Java 中的 git 服务器实现，它也恰好是非常强大的代码审查引擎（Android 项目也使用）。Gerrit 的代码审查功能是完全可选的（如果您不想使用，则不必使用它），但您一定会喜欢 Gerrit 的统一用户身份验证、ssh 密钥管理和控制每个 git 存储库的访问权限的能力。这使得分享给第 3 方变得非常方便 - 您只需使用 Gerrit 让他们访问小部件，您就完成了。
十多年来，我们有一个非常大的遗留 CVS 存储库 (66GiB)，并且还在不断增加。现在我们有一些分包公司，需要在一些模块和分支上工作。
我们需要为他们创建一些分支并将这些分支发送给他们。我们还需要不时将他们的更改合并到我们的主要分支中。
听起来您只想为分包商过渡，而不是为其他所有人。我强烈建议你不要这样做。要么转换所有人，要么不转换任何人。运行混合系统是一件非常痛苦的事情，尤其是在从 DVCS 上的人员那里获取更改时。
我们关心的是：
- 我们不能绝对给他们整个回购，主要是担心安全。
是您的 CVS 存储库中有多个模块，但不能给它们所有模块，或者您想限制它们可以访问的历史记录？
当模块存储为单独的存储库而不是一个存储库中的多个模块时，DVCS 工作得更好*。这有很多原因，但主要是为了不同模块中的更改不会导致不必要的合并。
（* CVCS 也是如此，但是创建一个人们只做一次的新模块通常会很痛苦。我怀疑如果它被拆分，你不会有 66GB。）
因此，如果您进行转换，则需要分离模块。这将允许您共享一些模块而不是其他模块。我知道 Mercurial 能够在转换期间从多模块存储库中设置的路径创建存储库。我希望 Git 具有类似的功能。
- 我们需要向他们发送一些历史信息，而不仅仅是“HEAD”版本的代码。
这几乎决定了 DVCS。这是一个定义属性。
- 我们仍在做一些开发工作，所以我们需要不时向他们发送变更集。
...这就是为什么您应该使用与他们相同的 VC 工具。否则，您将花费所有时间在系统之间转换变更集。
GIT 和 Mercurial 是从 CVS 迁移的好选择吗？GIT/Mercurial 能满足我们的需求吗？
是的，是的，但这不是按钮转换。它需要计划、承诺和教育。
编辑：我认为我们实际上需要一个具有多站点功能的集中式修订控制，能够基于部分中央回购创建异地回购。并且可以很容易地在站点之间合并。
一个集中但分布式的版本控制系统。被我耍到了！
最后一点，不要将集中/分布式开发实践与集中/分布式工具混淆。在具有分布式 VCS 的集中式开发模型中工作是完全合理的。
选择 git。如果可以的话，更喜欢子模块而不是树，因为您可以更好地控制项目与其各自子项目之间的依赖关系。
我会让其他发帖者回答子树和子历史问题，因为我对此并不熟悉。但是，我可以告诉你一些关于回购规模的事情。首先，你的 git repo 很可能比你的 CVS 小得多（我猜它会在当前 66GiB 的十分之一到一半之间）。
其次，是的，如果您将整个 CVS 存储库放入一个 git 存储库中，那么您的内部开发人员将在他们的个人 PC 上拥有整个存储库的副本。我每天使用的 git 存储库是 12GB，它不会引起任何实际问题。假设您的存储库很大，因为您的工作副本很大，当您想要在分支之间移动时，它实际上可以节省大量时间，因为您没有通过网络获取这么多文件。对我们来说，12GB 的 git repo 并不是什么大不了的事，因为我当前的工作副本（包含大多数目标的构建对象）是 git repo 本身之上的额外 37GB。在这种大小的存储库上，git 的命令比 subversion 的运行速度要快得多。
因此，请务必阅读其他人对子树和模块等的看法，但请放心，如果必须，您可能只导入整个内容。