相关疑难解决方法(0)

Subversion允许您使用外部嵌入其他存储库的工作副本,从而允许在项目中轻松控制第三方库软件.

虽然这些似乎是重用库和供应商软件版本控制的理想选择,但它们并非没有批评:

请不要使用Subversion外部(或其他工具中的类似),它们是反模式,因此是不必要的

使用外部设备是否存在隐患？请解释为什么他们会被视为反模式.

过去(这里和这里)有关于Hg子回购依赖关系的几个问题但是接受的答案似乎并没有解决我的问题.

我的一个项目有4个依赖项:A,B,C,D.D依赖于A,B和C; 而B和C依赖于A:

我想使用Hg子存储库来存储它们,以便我可以跟踪它们所依赖的每个版本.这是因为,当我用A,B,C和d在这个项目,其他项目将需要的只是A和B.因此,B和C必须独立于D来跟踪它们所需的A版本.同时,在我的应用程序中,给定版本的D引用的B和C版本必须始终使用与A引用的版本相同的A版本.给定版本的D(否则它将在运行时崩溃).我真正想要的是允许他们在同一目录中作为兄弟姐妹互相引用 - 即D's .hgsub看起来像下面这样,而B和C看起来就像是第一行.

..\A = https:(central kiln repo)\A
..\B = https:(central kiln repo)\B
..\C = https:(central kiln repo)\C

然而,这似乎不起作用:我可以看到为什么(给人们足够的绳索让自己挂起来很容易),但我觉得它是我的依赖关系的最佳解决方案,这是一种耻辱.我已经阅读了一些建议的解决方案,我会快速概述这些解决方案以及它们为什么不能为我工作:

1. 将副本包含为嵌套子目录,将这些副本引用为Hg子存储库.这会产生以下目录结构(我删除了A,B,C,B\A,C\A的主副本,因为我可以接受引用\ D中的副本):

   • project \(所有主要项目文件)
   • 项目\ d
   • 项目\ d\A
   • 项目\ d \乙
   • 项目\ d\B \一
   • 项目\ d\C
   • 项目\ d\C\A

   这种方法的问题:

   • 我现在在磁盘上有3个A副本,所有这些副本都可以进行独立修改,在推送到中央仓库之前必须同步并合并.
   • 我必须使用其他机制来确保B,C和D引用相同版本的A(例如D可以使用v1而D\B可以使用v2)

2. 变体:使用上面但指定.hgsub的RHS指向父副本中的副本(即B和C应该具有下面的.hgsub):

   A = ..\A
   

   Run Code Online (Sandbox Code Playgroud)

   这种方法的问题:

   • 我仍然在磁盘上有三个副本
   • 第一次克隆B或C时,它将尝试递归地从"..\A"中提取A的引用版本,这可能不存在,可能会导致错误.如果它不存在,则不知道应该找到回购的位置.
   • 当我进行递归推送更改时,D\B\A中的更改不会进入共享的中央存储库; 他们只是被推到D\A而不是.因此,如果我连续两次推送,我可以保证所有更改都会正确传播,但这是一个相当的软糖.
   • 类似地,如果我做(手动)递归拉动,我必须得到正确的顺序以获得最新的更改(即在我拉D\B\A之前拉D\A)

3. 使用符号链接将文件夹\ D\B\A指向D\A等.

   这种方法的问题:

   • 符号链接无法在Hg repo本身中进行编码,因此每次团队成员克隆回购时,他们都必须手动/使用脚本重新创建符号链接.这可能是可以接受的,但我更喜欢更好的解决方案.另外(个人喜好)我发现符号链接非常不直观.

这些是最好的解决方案吗？我的初始.hgsub(见上)是一个梦想有没有一个很好的理由,还是有办法我可以请求/实现这个改变？

更新以更好地解释A,B,C,D的更广泛使用

此问题与使用Mercurial hgsubversion扩展与SVN外部相关.但是,有关做a的问题的第二部分hg svn update尚未得到答复.

是否有可能将您提取的subversion存储库中的SVN外部转换为Mercurial子存储库？