我们正在改变源代码管理系统，我们目前正在评估git和mercurial。总代码库大约有600万行代码，因此不是很大，也不是很小。
首先让我简单介绍一下当前存储库设计的外观。
我们有一个完整代码库的基本文件夹，在该级别下面有几个不同的上下文中使用的各种模块。例如，“dllproject1”和“dllproject2”可以看作是完全独立的项目。
我们正在开发的软件是我们称之为配置器的软件，可以根据不同的客户需求进行无限制定制。总共我们可能有50个不同的版本。但是，他们有一个共同点。它们共享一些必需的模块（mandatory_module1 ..）。这些文件夹基本上包含内核/核心代码和公共语言资源等。然后，所有自定义都可以是其他模块（module1 ..）之间的任意组合。
由于我们目前正在使用cvs，因此我们在CVSROOT / modules文件中添加了别名。它们可能看起来像：
core –a mandatory_module1 mandatory_module2 mandatory_module3
project_x –a module1 module3 module5 core
因此，如果有人决定使用project_x，他/她可以快速签出所需的模块：
base>cvs co project_x
直观地将基本文件夹作为单个存储库感觉是错误的。作为程序员，您应该能够查看当前正在使用的项目所需的确切代码子集。你对此有何看法？
另一方面，将每个模块放在不同的存储库中感觉更为正确。但这使得程序员更难以检查出他们需要的模块。您应该能够通过一个命令执行此操作。所以我的问题是：是否有类似的方法在git / mercurial中定义别名？
非常欢迎任何其他问题，建议和指示！
PS。我已经搜索了类似的问题，但并不认为他们中的任何一个都100％适用于我的情况。
答案 0 :(得分：13)
快速评论提醒您：
然后使用submodules作为定义configuration的方式。
[...] CVS，即它真的最终面向“一个文件” 在一次“模特。
这很好，你可以有一百万个文件，然后只检查 他们中的一些 - 你甚至不会看到对方的影响 999,995个文件。
GIT中 从根本上说，从来没有真正看过不到整个回购。即使你 限制一些事情（即只检查一部分，或有历史记录 回来一点），git最终仍然关心整个事情， 并传授知识。
如果你强迫它把所有东西看成一个，那么git的表现就会非常糟糕 巨大的存储库。我不认为那部分是可以修复的，尽管我们 可能会改善它。
是的，那就是“大文件”问题。我真的不知道该怎么做 做大文件。我知道，我们很害羞。
上述两点主张为大型系统（以及大型遗留存储库）提供更加面向组件的方法。
使用Git submodule，您可以在项目中签出它们（即使这是一个两步骤的过程）。但是，您可以使用工具，而不是简化子模块管理（例如git.rake）。
当我正在考虑修复一个在多个项目之间共享的模块中的错误时，我只修复了错误并提交了它并且只是进行了更新
这就是我在帖子Vendor Branch中描述的“系统方法”：每个人都在处理所有事情的最新（HEAD），并且对少数项目有效。
但是对于大量的模块，“模块”的概念仍然非常有用，但它的管理与DVCS不同：
对于密切相关的模块（又名“在同一功能域中”，如“与PNL相关的所有模块 - 利润和损失 - 或”风险分析“，在金融领域中），您需要使用所涉及的所有组件的最新（HEAD）
这可以通过使用subtree strategy来实现，而不是为了在其他子模块上发布（推送）更正，而是为了跟踪其他团队完成的工作。
Git允许额外的奖励，这个“跟踪”不必在您的存储库和一个“中央”存储库之间进行，但也可以在您和另一个团队的本地存储库之间进行，允许非常快速在类似性质的项目之间来回整合和测试。
但是，对于不直接在您的功能域中的模块，子模块是更好的选择，因为它们指的是模块的修复版本（提交）：
当一个低级框架发生变化时，你不希望它立即传播 ，因为它会影响所有其他团队，然后他们必须放弃他们正在做的事情以使他们的代码适应那个新版本（你确实希望所有其他团队都知道这个新版本，以便他们不要忘记更新那个低级组件或“模块”）。
这允许您仅使用其他模块的官方稳定标识版本，而不是可能不稳定或未经过完全测试的HEAD。
答案 1 :(得分：5)
对于Mercurial方面，建议还要将大型遗留CVS / SVN存储库重构为更小的组件。应将通用代码放入其自己的库中，然后应用程序代码将依赖于这些库，其方式与它依赖于其他库的方式类似。
Mercurial拥有forest extension，允许您管理“源树”的“森林”。使用该方法，您可以将几个较小的存储库组合成一个较大的存储库。使用CVS，您可以做相反的事情：检查大型存储库的一小部分。
我没有亲自使用过森林扩展，其页面上说应该使用与Mercurial捆绑的版本相比更新版本。但是， 在其OpenJDK project中由像Sun这样的大型组织使用。
目前正在进行工作，根据Mercurial wiki中nested repositories page的设计，将子存储库报告直接添加到Mercurial的核心。