汞子库的依赖性 [英] Hg sub-repository dependencies
问题描述
过去，关于Hg子仓库依赖关系有几个问题(此处)，但似乎无法为我解决问题.
There have been a couple of questions about Hg sub-repo dependencies in the past (here and here) but the accepted answers don't seem to address the problem for me.
我的一个项目有4个依赖项:A，B，C，D.D依赖于A，B和C； D依赖于A，B和C. B和C取决于A:
A project of mine has 4 dependencies: A, B, C, D. D is dependent on A, B and C; and B and C are dependent on A:
的依赖图
我想使用Hg子存储库来存储它们，以便跟踪它们所依赖的每个版本.这是因为，当我在该项目中使用A，B，C和D时，其他项目将只需要A和B .因此，B和C必须独立于D来跟踪它们需要的A版本.同时，在我的应用程序中，给定D版本引用的B和C版本必须始终使用与D版本引用的A版本相同的版本.给定的D版本(否则它将在运行时崩溃).我真正想要的是允许他们在同一目录中以兄弟姐妹的身份互相引用-即D的.hgsub看起来像下面，B和C的看起来像第一行.
I want to use Hg sub-repositories to store them so I can track what version of each they rely on. This is because, while I am using A,B,C and D in this project, other projects will require just A and B. Therefore B and C must track what version of A they need independently of D. At the same time, in my application the versions of B and C referenced by a given version of D must always use the same version of A as that referenced by the given version of D (otherwise it will just fall over at runtime). What I really want is to allow them to reference each other as siblings in the same directory - i.e. D's .hgsub would look like the following, and B and C's would look like the first line.
..\A = https:(central kiln repo)\A
..\B = https:(central kiln repo)\B
..\C = https:(central kiln repo)\C
但是，这似乎不起作用:我可以理解为什么(很容易给人们足够的绳索来挂自己)，但是这很可惜，因为我认为这是解决依赖项的最巧妙的方法.我已经阅读了一些建议的解决方案，这些解决方案将为我快速概述，以及为什么它们对我不起作用:
However this doesn't seem to work: I can see why (it'd be easy to give people enough rope to hang themselves with) but its a shame as I think its the neatest solution to my dependencies. I've read a few suggested solutions which I'll quickly outline and why they don't work for me:
-
将副本包含为嵌套子目录，将其称为Hg子存储库.这将产生以下目录结构(我已经删除了A，B，C，B \ A，C \ A的主要副本，因为我可以接受引用\ D内的副本):
Include copies as nested sub-directories, reference these as Hg sub-repositories. This yields the following directory structure (I've removed the primary copies of A, B, C, B\A, C\A as I can accept referencing the copies inside \D instead):
- 项目\(所有主项目文件)
- 项目\ D
- 项目\ D \ A
- 项目\ D \ B
- 项目\ D \ B \ A
- 项目\ D \ C
- 项目\ D \ C \ A
这种方法存在的问题:
- 我现在在磁盘上有3个A副本，所有这些副本都可以进行独立修改，必须先进行同步和合并，然后再推送到中央存储库.
- 我必须使用其他机制来确保B，C和D引用相同版本的A(例如D可以使用v1，而D \ B可以使用v2)
变体:使用以上内容，但指定.hgsub的RHS指向父副本中的副本(即B和C在下面应具有.hgsub):
A variation: use the above but specify the RHS of the .hgsub to point to a copy in the parent copy (i.e. B and C should have the .hgsub below):
A = ..\A
这种方法存在的问题:
- 我的磁盘上还有3个副本
- 我第一次克隆B或C时，它将尝试从".. \ A"(可能不存在)中递归提取A的引用版本.如果不存在，则无法找到应该在何处回购的线索.
- 当我递归地进行更改时，D \ B \ A中的更改不会进入共享的中央存储库；他们只是被推送到D \ A而已.因此，如果我连续两次按下按钮，则可以保证所有更改都将正确传播，但这实在是个错误.
- 类似地，如果我执行(手动)递归拉，则必须正确获得最新更改的命令(即，在拉D \ B \ A之前先拉D \ A)
使用符号链接将文件夹\ D \ B \ A指向D \ A等.
Use symlinks to point folder \D\B\A to D\A etc.
这种方法存在的问题:
- 符号链接无法在Hg存储库本身中进行编码，因此每次团队成员克隆存储库时，他们都必须手动/使用脚本重新创建符号链接.这可能是可以接受的，但我希望有一个更好的解决方案.另外(个人喜好)，我发现符号链接非常不直观.
这些是最好的可用解决方案吗?我的最初的.hgsub(请参见顶部)是梦dream以求的理由吗?或者我可以请求/实现此更改吗?
Are these the best available solutions? Is there a good reason why my initial .hgsub (see top) is a pipe-dream, or is there a way I can request/implement this change?
已更新以更好地解释A，B，C，D的更广泛用法
UPDATED to better explain the wider usage of A,B,C,D
推荐答案
与其尝试通过Mercurial(或与此相关的任何SCM)来管理依赖项，不如尝试使用依赖项管理工具，例如 Apache Ivy .
Instead of trying to manage your dependencies via Mercurial (or with any SCM for that matter), try using a dependency management tool instead, such as Apache Ivy.
使用基于Ivy的方法，您没有任何子存储库，您将只有项目A，B，C和D.A会生成工件(例如.jar，.so或.dll等) ，该版本会发布到工件版本库(基本上是保存构建工件的地方)中，并带有一个版本.然后，项目B和C可以依赖于A的特定版本(通过每个项目中的ivy.xml文件进行控制)，Ivy将从工件存储库中检索该版本.项目B和C还产生了人工制品，这些人工制品已发布到您的存储库中.项目D依赖于B和C，并且可以告诉Ivy过渡地检索依赖关系，这意味着它将获得B，C和A的工件(因为它们依赖于A).
Using an Ivy based approach, you don't have any sub-repos, you would just have projects A, B, C and D. A produces an artifact (e.g. a .jar, .so or .dll, etc), which is published into an artifact repository (basically a place where you keep your build artefacts) with a version. Projects B and C can then depend on a specific version of A (controlled via a ivy.xml file in each project) which Ivy will retrieve from the artifact repository. Projects B and C also produce artefacts that are published to your repository. Project D depends on B and C and Ivy can be told to retrieve the dependencies transitively, which means it will get the artifacts for B, C and A (because they depend on A).
类似的方法可以用于 Apache Maven 和
A similar approach can be used with Apache Maven and Gradle (the later uses Ivy)
主要优点是:
- 非常清楚地说明了项目正在使用的每个组件的版本(有时人们忘记检查
.hgsub，因此他们不知道自己正在使用subrepos)， - 这使得更改依赖项目成为不可能(因为您正在使用工件而不是代码)
- 它使您不必重新构建依赖项目，也不必确定您使用的是哪个版本.
- 使您避免拥有其他项目使用的多个项目冗余副本.
- it makes it very clear what versions of each component a project is using (sometimes people forget to check
.hgsub, so they don't know they are working with subrepos), - it makes it impossible to change a dependant project (as you are working with artifacts, not code)
- and it saves you from having to rebuild dependent projects and being unsure of what version you are using.
- saves you from having multiple redundant copies of projects that are used by other projects.
在 查看全文
