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