Mercurial 子存储库 - 管理更复杂的依赖关系层次结构
我有一个主项目，它使用相当标准的源代码树方法+ 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副本！
所以我知道在引用子存储库（= 的 RHS）时我应该使用相对路径——但这对我理解的场景没有帮助。我认为没有任何方法可以使 LHS 在主存储库之外运行，而我认为这是我真正需要的。
关于如何解决这个问题，我有一些想法，但没有一个适合我，我认为必须有更好的方法。我理想的解决方案允许我在多个项目之间共享相同的子存储库，而无需支付拥有多个副本的惩罚。在我的场景中，这似乎既浪费又低效（另外，我希望所有依赖 Sub1 的项目都使用相同的 hg 修订版，而不是独立修订）
将 Sub1 作为 Master 的子存储库删除，并更改 Master 解决方案中的任何相对路径以引用双重嵌套的 Sub1。这个路径结构不仅丑陋，而且如果向 master 添加一个依赖于 Sub1 的 Sub3，我仍然有 2 个 Sub1 副本。
编译 Sub1 的副本并将其放入 \lib 目录中。 Sub1 仍在经历一些改动，我宁愿根据源版本进行构建。我不想一直不断地将新的二进制文件复制到源树（并使树膨胀）。
以某种方式打破 Sub2 对 Sub1 的依赖。根据存储库的架构，这可能不会发生。 Sub1 包含一些非常通用的共享库代码。 Sub2 包含两个非常独立的项目（客户端 SDK 和服务器实现）所需的 WCF 服务契约/接口/类型。此时，将这些存储库分开是有意义的。
也许我的想法是错误的......或者也许我不知道一些汞的技巧。
任何帮助表示赞赏。
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)
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.
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).
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我想说，忘记签入二进制文件，这只会导致存储库膨胀。 IMO，构建的任何输出都不应该存储在源存储库中。
教 Sub2 期待在 ../Sub1 找到 Sub1 怎么样？然后，如果您发现需要独立于 Sub1 处理 Sub2，请创建一个“Sub2_standalone”存储库，将 Sub1 和 Sub2 作为子存储库引入。
所以，当处理所有事情时，你会得到：
但是当只处理 Sub2 时：
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:
But when just working on Sub2:
如果您需要该嵌套结构，则可以在 Sub2 下面使用 Sub1 的符号链接，以确保 Sub1 的两个版本始终处于同一修订版。那么你实际上只有一个 Sub1 版本，这似乎就是你想要的。
在 GNU/Linux 上，这将是一个简单的 ln -s source/contrib/Sub1 source/contrib/Sub2/source/contrib/Sub1
If you need that nested structure, you could use a symlink for Sub1 below Sub2, to ensure that both versions of Sub1 are always at the same revision. Then you actually have only one version of Sub1, which seems to be what you want.
On GNU/Linux it wouly be a simple
ln -s source/contrib/Sub1 source/contrib/Sub2/source/contrib/Sub1