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

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 在Master存储库之外生存,我认为这是我真正需要的.

关于如何解决这个问题,我有几个想法,但没有一个与我坐在一起,我认为必须有更好的方法.我理想的解决方案允许我在多个项目中共享相同的子仓库,而不会支付多个副本的罚款.在我的场景中,这似乎是浪费和低效的(另外,我希望所有依赖于Sub1的项目使用相同的hg修订版,而不是单独修改)

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

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

3. 以某种方式打破了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