如果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項目。