Mercurial子存储库-管理更复杂的依赖关系层次结构 [英] Mercurial subrepositories - managing more complex dependency hierarchies

问题描述

我有一个主项目，该项目正在使用相当标准的源代码树方法+商业子存储库.

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

关于如何解决此问题，我有一些想法，但是没有一个想法对我有利，我认为必须有更好的方法.我理想的解决方案使我可以在多个项目之间共享同一个子仓库，而无需支付多个副本的代价.在我的情况下，这似乎是浪费和低效的(此外，我想让所有依赖Sub1的项目都使用相同的hg修订版，而不是独立进行修订)

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

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

I have a master project that's using a fairly standard source tree approach + mercurial subrepositories.

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

Now, it was recently determined that Sub2 needs some code from Sub1, and hence I have to adjust for this new dependency structure.

The problem of course is that if I follow the same approach as above and add Sub1 as a subrepos of Sub2, I end up with this ugly situation.

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

Master now has 2 independent copies of Sub1!

So I know that I should be using relative paths when referencing subrepos (the RHS of the =) -- but that won't help out my scenario here as I understand it. I don't think there's any way to make the LHS live outside of the Master repository, which I think is what I really need here.

I have a couple of ideas on how to fix this, but none sits right with me, and I assume there has to be a better way. My ideal solution allows me to share the same sub-repo amongst multiple projects w/out paying the penalty of having multiple copies around. That just seems wasteful and inefficient in my scenario here (plus, I'd like to have all projects that have a dependency on Sub1 to use the same hg revision, rather than being revisioned independently)

1. Remove Sub1 as a subrepos of Master, and change any relative paths in the Master solution to reference the doubly nested Sub1. Not only is this path structure hideous, but if add a Sub3 to master that has a dependency on Sub1, I still have 2 copies of Sub1.

2. Compile a copy of Sub1 and just chuck it in the \lib directory. Sub1 is still undergoing some churn, and I'd rather build against the source versions. I don't want to pay the tax of constantly copying in new binaries to the source tree all the time (and bloating the tree).

3. Somehow break the dependency of Sub2 on Sub1. Based on the architecture of the repositories, this is probably not going to happen. Sub1 contains some very general purpose shared library code. Sub2 contains WCF service contract / interface / types that is needed in two very separate projects -- a client SDK and server implementation. At this point in time, it makes sense to keep these repositories separate.

Maybe I'm thinking about this wrong... or maybe I'm unaware of some hg trick.

Any help is appreciated.

解决方案

I'd say, forget about checking in binaries, that just leads to repository bloat. IMO, any output from a build should not be stored in the source repository.

How about teaching Sub2 to expect to find Sub1 at ../Sub1? Then, if you find you need to work on Sub2 independently of Sub1, create a "Sub2_standalone" repo, that pull in Sub1 and Sub2 as sub-repos.

So, when working on everything, you'd get:

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

But when just working on Sub2:

Sub2_standalone/
Sub2_standalone/Sub2
Sub2_standalone/Sub1

这篇关于Mercurial子存储库-管理更复杂的依赖关系层次结构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！