Question

我有一个使用相当标准的源树方法+ 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版本，而不是独立修改）

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

编译Sub1的副本，然后将其放入\ lib目录中。 Sub1仍在进行一些流失，我宁愿建立源版本。我不想在新的二进制文件中不断地复制到源树的税（并且在树上膨胀）。

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

也许我正在考虑这个错误......或者我可能没有意识到某些技巧。

感谢任何帮助。

Answer 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

Answer 2

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

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

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

2 个答案: