5

我有一个使用相当标准的源代码树方法 + 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副本！

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

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

  1. 删除 Sub1 作为 Master 的子存储库，并更改 Master 解决方案中的任何相对路径以引用双重嵌套的 Sub1。这种路径结构不仅可怕，而且如果将 Sub3 添加到依赖于 Sub1 的主控，我仍然有 2 个 Sub1 副本。

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

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

也许我在想这个错误......或者我可能不知道一些汞技巧。

任何帮助表示赞赏。

4

2 回答 2

2

我会说，忘记签入二进制文件，这只会导致存储库膨胀。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
于 2011-01-24T21:36:58.870 回答
0

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

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

于 2011-01-25T05:45:27.583 回答