Mercurial 子存储库 - 管理更复杂的依赖层次结构答案

【问题标题】：Mercurial subrepositories - managing more complex dependency hierarchiesMercurial 子存储库 - 管理更复杂的依赖层次结构
【发布时间】：2011-06-14 18:33:30
【问题描述】：

我有一个使用相当标准的源代码树方法 + 反复无常的子存储库的主项目。

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 现在拥有 Sub1 的 2 个独立副本！

所以我知道在引用 subrepos（= 的 RHS）时我应该使用相对路径——但据我了解，这对我的场景没有帮助。我不认为有任何方法可以使 LHS 在主存储库之外运行，我认为这是我在这里真正需要的。

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

将 Sub1 作为 Master 的子存储库删除，并更改 Master 解决方案中的任何相对路径以引用双重嵌套的 Sub1。这个路径结构不仅可怕，而且如果添加一个依赖于 Sub1 的 Sub3 到 master，我仍然有两个 Sub1 的副本。
编译 Sub1 的副本并将其放入 \lib 目录。 Sub1 仍在经历一些混乱，我宁愿针对源版本进行构建。我不想一直为不断地将新的二进制文件复制到源代码树（并使树膨胀）而付出代价。
以某种方式打破 Sub2 对 Sub1 的依赖关系。根据存储库的架构，这可能不会发生。 Sub1 包含一些非常通用的共享库代码。 Sub2 包含两个非常独立的项目（客户端 SDK 和服务器实现）所需的 WCF 服务合同/接口/类型。目前，将这些存储库分开是有意义的。

也许我在想这个错误......或者也许我没有意识到一些 hg 技巧。

感谢任何帮助。

【问题讨论】：

标签： mercurial subrepos

【解决方案1】：

我会说，忘记签入二进制文件，这只会导致存储库膨胀。 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

【讨论】：

好吧，我想这不是一个完全糟糕的解决方案，我认为只要我在“兄弟”类型设置中总是有依赖代码，这应该可以解决问题。当然，我最终也会在 Mercurial 中使用一个额外的存储库来保持兄弟姐妹在一起，但这可能是我必须做出的权衡。谢谢你的想法——我没有考虑过。
虽然还没有准备好将其标记为答案 - 希望来自 selenic 的人会加入“最佳实践”;0
一个额外的存储库不应该受到伤害，因为它应该为存储库中的文件使用硬链接。
我知道从磁盘空间的角度来看它不会受到伤害......不用担心。如果您从 Web 视图查看存储库列表，我只是认为它可能会增加一些混乱。但这不是目前除了我之外的许多用户会做的事情......
好的——最终实现了这种方法，到目前为止，一切都很好。解决方案假定任何源依赖项都位于使用相对路径的同级文件夹中。我还设法将我们充满构建工具的文件夹也拉到了它自己的存储库中。用于拉取的“可用”项目最终只是 X 子存储库的包装器，其中 .hgsub 指定相对路径 - 即 Sub1 = ../Sub1 - 以及在某些情况下从 subs 中拉入适当项目的解决方案文件。如果我们也更改后端服务器，这具有使子存储库重新映射不必要的良好副作用。

【解决方案2】：

如果您需要该嵌套结构，您可以在 Sub2 下使用 Sub1 的符号链接，以确保 Sub1 的两个版本始终处于相同的修订版。那么你实际上只有一个版本的 Sub1，这似乎是你想要的。

在 GNU/Linux 上，这将是一个简单的 ln -s source/contrib/Sub1 source/contrib/Sub2/source/contrib/Sub1

【讨论】：

是的，我们都在 Windows 上。我曾考虑过类似的事情，但据我了解，符号链接不会被转换为 NTFS 连接——它们会转换为某种文件。我宁愿不走那条路
我实际上已经在 Windows 中通过 LinkShell 工具 (lifehacker.com/5530931/…) 使用了这种策略来达到同样的效果