mercurial - Hg 子存储库依赖项

Question

过去存在一些关于 Hg 子存储库依赖关系的问题( here 和 here )，但接受的答案似乎并不能解决我的问题。

我的一个项目有4个依赖:A、B、C、D。D依赖于A、B和C； B 和 C 依赖于 A:

我想使用 Hg 子存储库来存储它们，以便我可以跟踪它们所依赖的每个版本。这是因为，当我在这个项目中使用 A、B、C 和 D 时，其他项目将只需要 A 和 B。因此，B 和 C 必须独立于 D 跟踪它们需要的 A 版本。同时，在我的应用程序中，给定版本 D 引用的 B 和 C 版本必须始终使用与 D 的给定版本引用的 A 版本相同的版本。给定的 D 版本(否则它会在运行时崩溃)。我真正想要的是允许它们在同一目录中作为 sibling 相互引用 - 即 D 的 .hgsub 如下所示，而 B 和 C 的看起来像第一行。

..\A = https:(central kiln repo)\A
..\B = https:(central kiln repo)\B
..\C = https:(central kiln repo)\C

然而这似乎不起作用:我明白为什么(很容易给人们足够的绳子来吊死自己)但它是一种耻辱，因为我认为这是解决我的依赖关系的最巧妙的解决方案。我已经阅读了一些建议的解决方案，我将快速概述这些解决方案以及为什么它们对我不起作用:

1. 将副本包含为嵌套子目录，将它们引用为 Hg 子存储库。这会产生以下目录结构(我已经删除了 A、B、C、B\A、C\A 的主要副本，因为我可以接受引用\D 内的副本):

   • project\(所有主项目文件)
   • 项目\D
   • 项目\D\A
   • 项目\D\B
   • 项目\D\B\A
   • 项目\D\C
   • 项目\D\C\A

   这种方法的问题:

   • 我现在在磁盘上有 3 个 A 副本，所有这些副本都可以有独立的修改，必须在推送到中央存储库之前同步和 merge 这些修改。
   • 我必须使用其他机制来确保 B、C 和 D 引用 A 的同一版本(例如，D 可以使用 v1，而 D\B 可以使用 v2)

2. 变体:使用上述内容，但指定 .hgsub 的 RHS 以指向父副本中的副本(即 B 和 C 应该具有下面的 .hgsub):

   A = ..\A
   

   这种方法的问题:

   • 我的磁盘上仍然有三个副本
   • 第一次克隆 B 或 C 时，它将尝试从“..\A”递归地提取 A 的引用版本，该版本可能不存在，可能会导致错误。如果它不存在，则不会提供有关应该在哪里找到存储库的任何线索。
   • 当我递归推送更改时，D\B\A 中的更改不会进入共享中央存储库；他们只是被推到D\A。因此，如果我连续推送两次，我可以保证所有更改都会正确传播，但这完全是一个谎言。
   • 同样，如果我执行(手动)递归拉取，我必须确保顺序正确才能获取最新更改(即在拉取 D\B\A 之前拉取 D\A)

3. 使用符号链接(symbolic link)将文件夹\D\B\A指向D\A等。

   这种方法的问题:

   • 符号链接(symbolic link)无法在 Hg 存储库本身中进行编码，因此每次团队成员克隆存储库时，他们都必须手动/使用脚本重新创建符号链接(symbolic link)。这可能是可以接受的，但我更喜欢更好的解决方案。另外(个人喜好)我发现符号链接(symbolic link)非常不直观。

这些是最好的可用解决方案吗？我最初的 .hgsub (见顶部)是一个白日梦，是否有充分的理由，或者有什么方法可以请求/实现此更改？

已更新以更好地解释 A、B、C、D 的更广泛用法

Answer 1

不要尝试通过 Mercurial(或任何 SCM)来管理依赖项，而是尝试使用依赖项管理工具，例如 Apache Ivy 。

使用基于 Ivy 的方法，您没有任何子存储库，您只有项目 A、B、C 和 D。A 生成一个工件(例如 .jar、.so 或 .dll 等) ，它会与版本一起发布到工件存储库(基本上是保存构建工件的地方)。然后，项目 B 和 C 可以依赖于 A 的特定版本(通过每个项目中的 ivy.xml 文件控制)，Ivy 将从工件存储库中检索该版本。项目 B 和 C 还会生成发布到您的存储库的工件。项目 D 依赖于 B 和 C，并且 Ivy 可以被告知以传递方式检索依赖项，这意味着它将获得 B、C 和 A 的工件(因为它们依赖于 A)。

类似的方法可以用于 Apache Maven和 Gradle (后者使用Ivy)

主要优点是:

• 它非常清楚地表明项目正在使用的每个组件的版本(有时人们忘记检查.hgsub，因此他们不知道他们正在使用子存储库)，
• 这使得更改依赖项目变得不可能(因为您正在使用工件，而不是代码)
• 它使您不必重新构建依赖项目，也不必不确定您正在使用的版本。
• 使您不必拥有多个被其他项目使用的冗余项目副本。

编辑:类似的答案，但略有不同，位于 Best Practices for Project Feature Sub-Modules with Mercurial and Eclipse?