简介和背景
我们正在更改源代码控制系统，目前正在评估 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 中是否有类似的定义别名的方法？
任何其他问题、建议、指点都非常欢迎！
附言。我搜索过类似的问题，但觉得没有一个问题 100% 适用于我的情况。
只是一个简短的评论来提醒您：
- 这些迁移通常提供了重新组织源的机会，不是沿着模块（每个模块都有一个存储库），而是沿着功能域拆分（同一给定功能域的多个模块放入同一存储库中）。
Then 子模块被用作定义一个配置.
- Git 没问题，但是来自莱纳斯本人承认，将所有内容放入一个存储库可能会出现问题。
[...] CVS，即它实际上最终几乎面向“一个文件”
一次”模型。
这很好，因为你可以拥有一百万个文件，然后只检查
其中一些 - 你甚至永远不会see对方的影响
999,995 个文件。
git
从根本上来说，从来没有真正关注过整个仓库。即使你
限制一下事情（即只查看一部分，或者让历史记录消失）
稍微向后退一点），git 最终仍然总是关心整个事情，
并携带知识。
因此，如果你强迫 git 将所有东西视为一个整体，那么 git 的扩展性会非常糟糕huge存储库。我不认为这部分是真正可以修复的，尽管我们
也许可以改进它。
是的，还有“大文件”问题。我真的不知道该怎么办
处理大文件。我知道我们很讨厌他们。
上述两点主张对大型系统（和大型遗留存储库）采用更加面向组件的方法。
With Git 子模块，您可以在项目中查看它们（即使这是一个两步过程）。然而，您拥有的工具可以使子模块管理更容易（git.rake例如）。
当我考虑修复多个项目之间共享的模块中的错误时，我只需修复该错误并提交它，然后所有项目都只需进行更新
这就是我在帖子中描述的供应商分支机构作为“系统方法”：每个人都致力于最新的（HEAD）一切，并且对于少量项目来说是有效的。
虽然对于大量的模块来说，“模块”的概念仍然非常有用，但是它的管理与DVCS不一样：
对于密切相关的模块（又名“在同一功能领域”，例如“与财务领域中的 PNL - 利润和损失 - 或“风险分析”相关的所有模块），您确实需要使用最新的（HEAD）涉及的所有组件。
这可以通过使用子树策略，不是为了让您发布（推送）对其他子模块的更正，而是为了跟踪其他团队完成的工作。
Git 的额外好处是，这种“跟踪”不必在您的存储库和一个“中央”存储库之间进行，也可以在您和其他团队的本地存储库之间进行，从而可以非常快速地进行跟踪。类似性质的项目之间来回集成和测试。
但是，对于不直接位于功能域中的模块，子模块是更好的选择，因为它们引用模块的修复版本（提交）：
当低级框架发生变化时，您不希望它被传播瞬间，因为这会影响所有其他团队，然后这些团队必须放弃他们正在做的使代码适应新版本的工作（尽管您确实希望所有其他团队都了解这个新版本，以便他们能够不要忘记更新该低级组件或“模块”）。
这允许您仅使用其他模块的官方稳定识别版本，而不是潜在不稳定或未经过完全测试的 HEAD。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
