Question

采取这种回购结构：

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

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

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

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

采取以下步骤：

在客户端存储库中，更新到更改集0.这会将ProjectB和SharedLibrary更新为更早但匹配的修订版。
ProjectA现在与SharedLibrary不同步。第1步将SharedLibrary更新为比ProjectA所需的旧版本更新，该版本仍为1（小费）。
在Server repo中，我们希望将SharedLibrary更新为ProjectA的正确版本，因此我们在Server主仓库中运行hg update tip。这不会将SharedLibrary更新为正确的版本。它将SharedLibrary保留在与第一步相同的版本中。
返回客户端仓库并运行hg update tip。 SharedLibrary现在是ProjectA和ProjectB的正确版本。

服务器仓库中的更新似乎没有检查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}}在修订版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已更新为SharedLibrary中针对.hgsubstate中修订版0所述的修订版。

当您转到client时，server子序列不再位于SharedLibrary中{1}}修订版 1 中提及的修订版本。换句话说，.hgsubstate中的工作副本很脏 - server会导致提交新的server文件。

当您hg commit .hgsubstate时，

Mercurial 会保留此修改，这就是为什么您在更新时看到hg update未生效的原因。如果您想使子参数最新，请使用server。

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

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

我described this in more detail，但是您应该遵循recommendations并在服务器和客户端上保持相同的结构。使用SharedLibrary文件中的hg update -C路径来维护此结构。在服务器端将存储库链接在一起（请参阅我的other answer），以使单个存储库显示在几个不同的URL /目录下。

从subrepos开始时，beware of tight coupling。如果可以，那么尝试使用适当的依赖管理系统，例如Maven + Nexus，用于基于Java的项目。

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

1 个答案: