如何使用 Mercurial 子存​​储库来共享组件和依赖项？

我们使用 C# 开发 .NET 企业软件。我们正在寻求改进我们的版本控制系统。我以前使用过mercurial，并且一直在我们公司尝试使用它。然而，由于我们开发企业产品，我们非常关注可重用的组件或模块。我一直在尝试使用 Mercurial 的子存储库来管理组件和依赖项，但遇到了一些困难。以下是源代码控制/依赖管理的基本要求：

1. Reusable components
   1. 按源共享（用于调试）
   2. 依赖于第三方二进制文件和其他可重用组件
   3. 可以在消费产品的环境中进行开发并致力于源代码控制
2. Dependencies
   1. 产品依赖于第三方二进制文件和其他可重用组件
   2. 依赖项有自己的依赖项
   3. 应通知开发人员依赖项中的版本冲突

这是我一直在使用的 Mercurial 的结构：

可重复使用的组件：

SHARED1_SLN-+-docs
            |
            +-libs----NLOG
            |
            +-misc----KEY
            |
            +-src-----SHARED1-+-proj1
            |                 +-proj2
            |
            +-tools---NANT

第二个可重用组件，消耗第一个：

SHARED2_SLN-+-docs
            |
            +-libs--+-SHARED1-+-proj1
            |       |         +-proj2
            |       |
            |       +-NLOG
            |
            +-misc----KEY
            |
            +-src-----SHARED2-+-proj3
            |                 +-proj4
            |
            +-tools---NANT            

消耗这两种成分的产品：

PROD_SLN----+-docs
            |
            +-libs--+-SHARED1-+-proj1
            |       |         +-proj2
            |       |
            |       +-SHARED2-+-proj3
            |       |         +-proj4
            |       |
            |       +-NLOG
            |
            +-misc----KEY
            |
            +-src-----prod----+-proj5
            |                 +-proj6
            |
            +-tools---NANT

Notes

1. 回购协议采用大写字母格式
2. 所有子存储库都被假定为子存储库
3. 第 3 方（二进制）库和内部（源）组件都是位于 libs 文件夹中的子存储库
4. 第 3 方库保存在单独的 Mercurial 存储库中，以便使用项目可以引用库的特定版本（即旧项目可能引用 NLog v1.0，较新项目可能引用 NLog v2.0）。
5. 所有 Visual Studio .csproj 文件都位于第 4 级（proj* 文件夹），允许对依赖项进行相对引用（即 ../../../libs/NLog/NLog.dll 对于引用 NLog 的所有 Visual Studio 项目）
6. 所有 Visual Studio .sln 文件都位于第二级（src 文件夹），以便在将组件“共享”到使用组件或产品时不包含它们
7. 开发人员可以按照自己认为合适的方式自由组织源文件，只要源是使用 Visual Studio 项目的 proj* 文件夹的子级（即 proj* 文件夹可以有 n 个子级，包含各种源/资源）
8. 如果 Bob 正在开发 SHARED2 组件和 PROD1 产品，那么他在 PROD1_SLN 存储库中更改 SHARED2 源（例如属于 proj3 的源）并提交这些更改是完全合法的。我们不介意有人在消费项目的背景下开发库。
9. 内部开发的组件（SHARED1 和 SHARED2）通常按源包含在使用项目中（在 Visual Studio 中添加对项目的引用而不是浏览到 dll 引用）。这允许增强调试（单步进入库代码），允许 Visual Studio 管理何时需要重建项目（当修改依赖项时），并允许在需要时修改库（如上面的注释中所述）。

问题

1. 如果 Bob 正在处理 PROD1，而 Alice 正在处理 SHARED1，那么 Bob 如何知道 Alice 何时向 SHARED1 提交更改。目前，使用 Mercurial，Bob 被迫在每个子存储库中手动拉取和更新。如果他从 PROD_SLN 存储库推送/拉取到服务器，他永远不会知道子存储库的更新。这在以下位置进行了描述水星维基。当 Bob 从服务器提取最新的 PROD_SLN 时，如何通知他子存储库的更新？理想情况下，他应该收到通知（最好在拉取期间），然后必须手动决定他想要更新哪个子存储库。

2. 假设 SHARED1 引用 NLog v1.0（mercurial 中的 commit/rev abc），SHARED2 引用 Nlog v2.0（mercurial 中的 commit/rev xyz）。如果 Bob 在 PROD1 中吸收这两个组件，则应该让他意识到这种差异。虽然从技术上讲，Visual Studio/.NET 允许 2 个程序集引用不同版本的依赖项，但我的结构不允许这样做，因为对于依赖于 NLog 的所有 .NET 项目，NLog 的路径都是固定的。 Bob 如何知道他的两个依赖项存在版本冲突？

3. 如果 Bob 正在为 PROD1 设置存储库结构并希望包含 SHARED2，那么他如何知道 SHARED2 需要哪些依赖项？根据我的结构，他必须手动克隆（或在服务器上浏览）SHARED2_SLN 存储库，然后查看 libs 文件夹，或者查看 .hgsub 文件以确定他需要包含哪些依赖项。理想情况下，这将是自动化的。如果我在我的产品中包含 SHARED2，SHARED1 和 NLog 也会自动包含在内，如果与其他依赖项存在版本冲突，则会通知我（请参阅上面的问题 2）。

更大的问题

1. Mercurial 是正确的解决方案吗？

2. 有没有更好的水银结构？

3. 这是子存储库的有效用途吗（即 Mercurial 开发人员标记为subrepos作为最后手段的功能）？

4. 使用 Mercurial 进行依赖管理是否有意义？我们可以使用另一个工具进行依赖关系管理（也许是内部 NuGet feed？）。虽然这对于第 3 方依赖项来说效果很好，但它确实会给内部开发的组件带来麻烦（即，如果它们是积极开发的，开发人员将不得不不断更新源，我们将不得不在内部为它们提供服务，并且不允许由使用项目修改的组件（注释 8 和问题 2）。

5. 对于企业 .NET 软件项目，您有更好的解决方案吗？

参考

我读过几个SO问题并发现this one能够提供帮助，但是接受的答案建议使用专用工具来处理依赖关系。虽然我喜欢这种工具的功能，但它不允许从消费项目修改和提交依赖项（请参阅更大的问题 4）。

这可能不是您正在寻找的答案，但我们最近有 Mercurial 新手用户使用子存储库的经验，我一直在寻找机会传递我们的经验......

总结来说，根据经验我的建议是：无论 Mercurial 子存​​储库多么吸引人，都不要使用它们。相反，找到一种方法来并排放置目录，并调整构建来应对这种情况。

无论将子存储库中的修订与父存储库中的修订结合在一起似乎很有吸引力，但它在实践中行不通。

在转换的所有准备过程中，我们收到了来自多个不同来源的建议，认为子存储库很脆弱并且实施得不好 - 但我们还是继续前进，因为我们希望在存储库和子存储库之间进行原子提交。这些建议——或者我对它的理解——更多地谈论了原则而不是实际后果。

直到我们使用 Mercurial 和子存储库后，我才真正正确地理解了这些建议。这里（凭记忆）是我们遇到的各种问题的示例。

• 您的用户最终将与更新和合并过程作斗争。
• 有些人会更新父仓库而不是子仓库
• 有些人会从子存储库推送，ang .hgsubstate 将不会更新。
• 您最终将“丢失”在子存储库中所做的修订，因为有人会在合并后设法使 .hgsubstate 处于错误状态。
• 有些用户会遇到 .hgsubstate 已更新但子存储库尚未更新的情况，然后您会收到非常神秘的错误消息，并且会花费很多时间尝试弄清楚发生了什么。
• 如果您对版本进行标记和分支，则如何为父存储库和子存储库做好此操作的说明将长达数十行。 （我什至有一位友善、温顺的 Mercurial 专家帮助我编写说明！）

所有这些事情对于专家用户来说已经够烦人的了——但是当你向新手用户推出 Mercurial 时，它们就是一场真正的噩梦，并且是浪费大量时间的根源。

因此，在投入大量时间来进行子存储库转换后，几周后我们将子存储库转换为存储库。因为我们在通过 .hgsubstate 引用子存储库的转换中有大量历史记录，所以它给我们留下了更复杂的东西。

我只希望我能早点真正理解所有建议的实际后果，例如在 Mercurial 的最后的手段的特点 page:

但我需要管理子项目！

再说一次，不要那么确定。像 Mozilla 这样具有大量依赖项的重要项目在不使用子存储库的情况下也能正常工作。大多数小型项目在不使用子存储库的情况下几乎肯定会更好。

编辑：思考shell 仓库

有了免责声明，我对他们没有任何经验......

不，我不认为他们中有很多人是这样的。您仍在使用子存储库，因此所有相同的用户问题都适用（当然，除非您可以为每个步骤提供包装器脚本，以消除人类提供处理子存储库的正确选项的需要。）

另请注意，您引用的 wiki 页面确实列出了 shell 存储库的一些具体问题：

• 过于严格地跟踪project/和somelib/之间的关系
• 无法检查或推送项目/如果某些lib/源代码库变成
• 不可用 缺乏对递归 diff、log 和 的明确支持
• 提交的状态递归性质令人惊讶

编辑 2 - 进行试用，让所有用户参与

当多个用户开始提交、拉取和推送时，我们才真正开始意识到我们遇到了问题——包括对子存储库的更改。对我们来说，现在回应这些问题已经太晚了。如果我们早点认识他们，我们的反应就会更容易、更简单。

所以在这一点上，我认为我能提供的最好建议就是推荐你在布局刻板之前对项目布局进行试运行.

我们等到全面试验时已经太晚了，无法进行更改，即使这样，人们也只在父存储库中进行更改，而不是子存储库 - 所以我们仍然没有看到全貌，直到为时已晚。

换句话说，无论您考虑什么布局，都可以在该布局中创建一个存储库结构，并让很多人进行编辑。尝试将足够的真实代码放入各种存储库/子存储库中，以便人们可以进行真正的编辑，即使它们将是一次性的。

可能的结果：

• 您可能会发现一切正常 - 在这种情况下，您将花费一些时间来获得确定性。
• 另一方面，您可能会比花时间尝试找出结果更快地发现问题
• 您的用户也会学到很多东西。