Mercurial 子存​​储库 - 管理更复杂的依赖关系层次结构

我有一个主项目，它使用相当标准的源代码树方法+ Mercurial 子存​​储库。

Master
\lib - compiled binaries - things like log4net, AutoFac, etc
\source - VS solution, one folder per project, etc
\tools - stuff used during the build process

\source\contrib - contains any subrepos like so:

\source\contrib\Sub1
\source\contrib\Sub2

Master\.hgsub contains something like
source\contrib\Sub1 = https://myserver.com/Sub1

现在，最近确定 Sub2 需要 Sub1 的一些代码，因此我必须针对这个新的依赖结构进行调整。

当然，问题是，如果我遵循与上面相同的方法并将 Sub1 添加为 Sub2 的子存储库，我最终会遇到这种丑陋的情况。

\source\contrib\Sub2\source\contrib\Sub1

Master现在拥有2个独立的Sub1副本！

所以我知道在引用子存储库（= 的 RHS）时我应该使用相对路径——但这对我理解的场景没有帮助。我不认为有什么办法可以让 LHS 活下去outside主存储库，我think这是我真正需要的。

关于如何解决这个问题，我有一些想法，但没有一个适合我，我认为必须有更好的方法。我理想的解决方案允许我在多个项目之间共享相同的子存储库，而无需支付拥有多个副本的惩罚。在我的场景中，这似乎既浪费又低效（另外，我希望所有依赖 Sub1 的项目都使用相同的 hg 修订版，而不是独立修订）

1. 删除 Sub1 作为 Master 的子存储库，并更改 Master 解决方案中的所有相对路径以引用双重嵌套的 Sub1。这个路径结构不仅丑陋，而且如果向 master 添加一个依赖于 Sub1 的 Sub3，我仍然有 2 个 Sub1 副本。

2. 编译 Sub1 的副本并将其放入 \lib 目录中。 Sub1 仍在经历一些改动，我宁愿根据源版本进行构建。我不想一直不断地将新的二进制文件复制到源树（并使树膨胀）而付出代价。

3. 以某种方式打破 Sub2 对 Sub1 的依赖。根据存储库的架构，这可能不会发生。 Sub1 包含一些非常通用的共享库代码。 Sub2 包含两个非常独立的项目（客户端 SDK 和服务器实现）所需的 WCF 服务契约/接口/类型。此时，将这些存储库分开是有意义的。

也许我的想法是错误的......或者也许我不知道一些 hg 技巧。

任何帮助表示赞赏。

我想说，忘记签入二进制文件，这只会导致存储库膨胀。 IMO，构建的任何输出都不应该存储在源存储库中。

教 Sub2 期待在 ../Sub1 找到 Sub1 怎么样？然后，如果您发现需要独立于 Sub1 处理 Sub2，请创建一个“Sub2_standalone”存储库，将 Sub1 和 Sub2 作为子存储库引入。

因此，在处理所有事情时，您会得到：

Master/
Master/source/contrib/Sub1  
Master/source/contrib/Sub2

但是当刚刚在 Sub2 上工作时：

Sub2_standalone/
Sub2_standalone/Sub2
Sub2_standalone/Sub1