如果子存储库属于两个主存储库，则汞更新不适用于子存储库？

Question

采用此回购结构：

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

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

假设每个主回购有两个变更集，0和1（提示）。我们从1（提示）修订版的两个主要回购开始。

采取以下步骤：

1. 在客户端回购中，更新到变更集0。这会将ProjectB和SharedLibrary更新为早期但匹配的修订版。

2. ProjectA现在与SharedLibrary不同步。步骤1将SharedLibrary更新为比ProjectA所需的版本旧的版本，ProjectA仍处于1（提示）。

3. 在Server repo中，我们希望将SharedLibrary更新为ProjectA的正确版本，因此我们在Server主repo中运行hg update tip。这不会将SharedLibrary更新为正确的修订版。它将SharedLibrary保留在与第一步相同的修订版中。

4. 返回到Client repo并运行hg更新提示。共享库现在处于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，修改将与修订版1:中的foo合并

$ 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

您确保CCD_ 6已更新为CCD_ 7中所述的CCD_。

当您转到server时，SharedLibrary子报表不再处于.hgsubstate中提到的server的修订版1中的修订版。换句话说，server中的工作副本是脏的——hg commit将导致提交新的.hgsubstate文件。

Mercurial在server中hg update时保留此修改，这就是为什么在更新时SharedLibrary未变为最新的原因。如果要使子报表成为最新的，请使用hg update -C。

这个功能背后的想法是，你可以测试你的子网站的不同版本。在寻找bug时，通常有必要将主存储库更新到旧版本，因此对子报表修订的修改保持不变很方便。

请注意，您所看到的令人困惑的情况并不是由于您两次重复使用同一子博客造成的。然而，正如Lasse所指出的，在多个项目中使用单个子Po的真正方法是将其放在服务器上一次，然后将其克隆到本地克隆中——每个克隆一次。

我已经对此进行了更详细的描述，但简要地说，您应该遵循建议，并在服务器和客户端上保持相同的结构。使用.hgsub文件中的SharedLibrary = SharedLibrary路径来维护此结构。将服务器端的存储库链接在一起（请参阅我的另一个答案），使单个存储库出现在几个不同的URL/目录下。

当开始使用subpos时，请注意紧密耦合。如果可以的话，那么试着为基于Java的项目使用适当的依赖性管理系统，比如Maven+Nexus。