是否有可能通過添加subrepos來重新更新？

我在我的資源庫中有一個文件夾。然後，我將這個文件夾作爲子庫（具有相同的文件），提交併推送此更改。現在我無法通過該提交進行更新。這是我得到的消息：是否有可能通過添加subrepos來重新更新？

% hg update --repository <path to repo> --config ui.merge=internal:fail --rev 1159 --clean 
abort: path 'subrepo\include\header.h' is inside nested repo 'subrepo' 
[command returned code 255 Wed Dec 05 11:57:45 2012]

哪裏subrepo就是subrepo現在居住在該文件夾的名稱。任何方式來擊敗這個並更新到早期版本？

來源

2012-12-05 Violet Giraffe

我剛剛有一個「玩」善變，它看起來就像是試圖做一個更新回你有subrepo把工作目錄中的「奇」狀態之前。例如，之後執行「hg update -C」會嘗試恢復文件，但不會正確設置工作目錄狀態（對我而言）。 'hg summary'報告父母是'-1：000000000000'，沒有檢出修訂。目前，我正在想這可能是一個錯誤報告 - 會多打一些... – icabod

@icabod：感謝您的時間，希望能爲進一步的調查結果。 –

發現了一個「解決方案」：刪除該文件夾並將其更新沒有問題（用「放棄更改」選項）。

來源

2012-12-05 16:14:49

但是請注意，在刪除該文件夾有丟失所以在該subrepo庫本地的修改的可能性。聽起來你的情況並不是問題，但是如果別人沒有意識到數據丟失的可能性，這可能會導致嚴重的問題。 – davidmc24

@ davidmc24：好點，儘管任何Mercurial用戶都應該明白，沒有提交和推送的更改將會丟失。我不認爲有任何問題提交，並且無論主要的回購狀態如何，都會對該子存儲庫進行更改。 –

經過一番Google搜索，看起來它與Caveat 3直接相關，引用「當前無法刪除子庫的更新/合併，因爲這可能會丟失僅本地更改」。另外需要注意的是，「正常文件和subrepos之間的衝突沒有處理」。

有趣的是，我之前沒有見過的東西，子版本庫被認爲是「feature of last resort」，這就是說，如果您可以幫助它，就應該儘量不要使用。

可能不是你要找的答案。

一種解決方法是通過克隆到你的修訂......你可以使用一個新的克隆基於某個版本創建的subrepo之前：

% hg clone --repository <path to repo> new_copy --rev 1159

這一切克隆到這一點，所以你會失去任何「未來的歷史」，但至少能夠回到以前的版本。

來源

2012-12-05 15:01:57 icabod

哦，好的。如果我只知道這些警告......謝謝。 –

您可以克隆回購高達以前的版本，但還沒有找到一種方法來在同一回購內更新。 – icabod

完美！我懷疑它應該是可能的，但還沒有找到命令。這將會訣竅。 –

是否有可能通過添加subrepos來重新更新？

回答

相關問題