gpt4 book ai didi

如果子 repo 属于两个主要 repo ,Mercurial 更新不适用于子 repo ?

转载 作者:行者123 更新时间:2023-12-02 02:17:49 27 4
gpt4 key购买 nike

采用这个 repo 结构:

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

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

SharedLibrary 指向同一个文件夹(这是 Windows),它不是每个主存储库下的单独副本/克隆。

假设每个主仓库有两个变更集,0 和 1(tip)。我们从 1(tip) 修订版的两个主要 repo 开始。

执行以下步骤:

  1. 在客户端存储库中,更新到变更集 0。这会将 ProjectB 和 SharedLibrary 更新到较早但匹配的修订版。

  2. ProjectA 现在与 SharedLibrary 不同步。第 1 步将 SharedLibrary 更新为比 ProjectA 所需版本更旧的版本,该版本仍为 1(tip)。

  3. 在服务器存储库中,我们希望将 SharedLibrary 更新为 ProjectA 的正确修订版,因此我们在服务器主存储库中运行 hg update tip。这不会将 SharedLibrary 更新为正确的修订版。它将 SharedLibrary 保留在与第一步相同的修订版中。

  4. 返回客户端 repo 并运行 hg update tip。 SharedLibrary 现在处于 ProjectA 和 ProjectB 的正确修订版本。

似乎服务器存储库中的更新没有检查 SharedLibrary 是否处于正确的修订版。这种行为是预期的,还是有更好的方法来做到这一点?

最佳答案

您看到的是 hg update 将在工作副本变脏时 merge 。我先用一个普通的文件来解释一下。假设您有一个包含两个修订版的存储库。我在修订版 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,修改将 merge 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 已更新到 .hgsubstate 中描述的版本,用于 client 中的版本 0。

当您随后转到 server 时,SharedLibrary 子存储库不再处于 .hgsubstate 中提到的修订版本 1 服务器 中。换句话说,server 中的工作副本是脏的 — hg commit 会导致提交新的 .hgsubstate 文件。

当您在 serverhg update 时,Mercurial 保留此修改,这就是您看到 SharedLibrary 的原因在您更新时成为最新的。如果您想使子仓库成为当前仓库,请使用 hg update -C

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

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

我已经 described this in more detail , 但简而言之,您应该遵循 recommendations并在服务器和客户端上保持相同的结构。在 .hgsub 文件中使用 SharedLibrary = SharedLibrary 路径来维护此结构。在服务器端将存储库链接在一起(参见我的 other answer ),使单个存储库出现在多个不同的 URL/目录下。

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

关于如果子 repo 属于两个主要 repo ,Mercurial 更新不适用于子 repo ?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/9668826/

27 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com