如果subrepo属于两个主要回购，Mercurial更新不适用于subrepo？

Question

借此回购结构：

Server (main repo) 
    ProjectA (subrepo) 
    SharedLibrary (subrepo) 

Client (main repo) 
    ProjectB (subrepo) 
    SharedLibrary (subrepo) 

SharedLibrary指向同一个文件夹（这是Windows）中，它不是每个主回购协议的单独副本/克隆。

假设每个主回购具有两个变更集，0和1（前端部）。我们从1（小费）版本的主要回购开始。

采取以下步骤：

1. 在客户端回购，更新变更集0.这将更新项目B和SharedLibrary较早，但匹配的修订版。

2. 项目A现在已经没有和SharedLibrary同步。步骤1将SharedLibrary更新为比ProjectA所需更旧的修订版，该修订版仍处于1（提示）。

3. 在服务器回购，我们要更新SharedLibrary为项目A正确的版本，所以我们运行在服务器主回购汞柱更新提示。这不会将SharedLibrary更新为正确的版本。它使SharedLibrary与第一步一样修订。

4. 回到客户端回购和运行hg的更新提示。 SharedLibrary现在对于ProjectA和ProjectB都是正确的版本。

它出现在服务器repo更新不检查，看看SharedLibrary是否在正确的修订版。这是行为预期，还是有更好的方法来做到这一点？

Answer 1

你看到的是hg update将合并当工作副本是脏的。让我先用普通文件解释一下。想象一下你有一个有两个版本的版本库。我在版本0和foo被修改为：

$ hg diff 
diff --git a/foo b/foo 
--- a/foo 
+++ b/foo 
@@ -1,3 +1,3 @@ 
first 
second 
-third 
+third line 

您看到我更改了第三行。现在，如果我跑hg update 1的修改将是合并着如何foo看起来像在修订版本1：

$ hg update 1 
merging foo 
0 files updated, 1 files merged, 0 files removed, 0 files unresolved 

的修改仍然存在，foo还是很脏：

$ hg diff 
diff --git a/foo b/foo 
--- a/foo 
+++ b/foo 
@@ -1,3 +1,3 @@ 
first line 
second 
-third 
+third line 

当你做

$ cd client 
$ hg update 0 

您确定SharedLibrary已更新至第e修订版client中的.hgsubstate中描述的版本。

当你后来去server，该SharedLibrary subrepo不再在server在.hgsubstate在修订提到的修订。换句话说，在server工作副本是脏 - 一个hg commit将导致新.hgsubstate提交文件的。

水银保留了这一修改当你serverhg update这就是为什么你看到SharedLibrary当你更新并没有取得电流。如果要制作subrepo电流，请使用hg update -C。

此功能背后的想法是，您可以测试不同版本的subrepos。在寻找错误时，通常需要将主版本库更新为旧版本，因此对子版本修订版本的修改保留在原位很方便。

请注意，您所看到的混乱情况，是不是受了你重复使用相同的subrepo两次造成的。然而，随着拉塞指出，在多个项目中使用单个subrepo真正的办法是把它一次您的服务器上，然后克隆它到本地克隆 - 一次每个克隆。

我已经described this in more detail，但简要地说，你应该遵循recommendations和维护服务器和客户端上相同的结构。在您的.hgsub文件中使用SharedLibrary = SharedLibrary路径来维护此结构。在服务器端将存储库链接在一起（请参阅我的other answer），以使单个存储库显示在多个不同的URL /目录下。

当开始接触subrepos，然后beware of tight coupling。如果可以的话，然后尝试使用适当的依赖关系管理系统，例如基于Java的Maven + Nexus项目。