維護開發/發佈分支​​的Mercurial最佳實踐？

Question

在我的辦公室，我們正在從Visual Source Safe（6.0！）過渡到Mercurial，並且我正在設法處理我們處境的最佳「Mercurial」方式。目前，在任何給定的項目存儲庫中，我們都維護了它的多個版本：即對於項目A，我們有ProjA-Dev，ProjA-Rel1和ProjA-Rel2的VSS回購（一個dev回購和過去兩年版本）。現在看來，幾乎所有新工作都在dev回購中進行，那麼被認爲需要回滾到Rel1或Rel2的更改是手動完成的（文件從VSS簽出到他們的自己的工作目錄，然後使用一些diff工具只複製適當的更改）。在某些時候，它被認爲會發佈一個新版本，所以dev repo被克隆，並且它變成了Proj * -Rev1，並且之前的Proj * -Rev1變成了Proj * -Rev2，並且Proj * -Dev只是繼續彷彿什麼也沒有發生。在我看來，必須有更好的方式來完成這個更現代的工具，如Mercurial。

我目前的想法是，每個項目應該有自己的存儲庫，Dev/Rel1/Rel2的區別最好由不同的命名分支來處理。然而，我無法弄清楚/看到/包裹我的頭是如何在這樣的環境下完成我們當前的工作流程。如果我們遵循我們當前的工作流程，那麼開發分支中的工作仍會繼續下去，並且某些更改（並非全部！）會回滾到Rel分支。我知道這可以通過Mercurial的移植/移植功能來完成，但它似乎還沒有在TortoiseHg中得到很好的支持。而且，更重要的是，過去的回答似乎表明，最好的解決辦法是不讓事情進入這種狀態，以1開頭。

問題是，鑑於當前工作流程，避免這種狀態的最佳方法是什麼？我已經閱讀了許多有關Mercurial和分支的指南（包括許多在這裏找到的答案），但沒有看到這個問題的明確答案。

Answer 1

我不知道這是否適合你，但我可以給你一些關於how Mozilla uses Mercurial的信息。我們每六週發佈一次Firefox，並且我們有幾個不同的分支並行運行：「夜間」從mozilla-central存儲庫構建，所有活動的開發都在這裏進行，「極光」來自mozilla-aurora存儲庫，我們試圖穩定代碼發佈，「測試版」從mozilla-beta存儲庫構建，我們在那裏執行最終驗證，並從mozilla-release存儲庫發佈構建版本。每個存儲庫都作爲獨立的克隆來維護。

The actual branch mechanics從一個分支移動到另一個分支有些複雜。這些分支都具有共同的歷史，但是由於極光和測試版分支在發佈之前將選定的安全性和穩定性修正移植到它們中，所以它們具有不同的歷史。確切的過程記錄在本段開頭的鏈接中，但歸結爲：「標記mozilla中央存儲庫;標記並關閉當前的mozilla-aurora頭部;將mozilla-central歸爲mozilla-aurora作爲新頭「。對於極光 - >測試，重複相同的過程。

從開發到極光或測試版分支的反向修復只是移植變更集的問題。如果你願意，你可以使用hg transplant命令，我記錄了我如何做到這一點。on my blog。

所有這些說法，這可能是對大多數項目來說矯枉過正。我們使用單獨的存儲庫克隆而不是命名分支，因爲我們對命名分支的工具不是很好，我們實際上更喜歡它給我們的隔離。您可以在這裏使用命名分支進行輕量級進程，只需在準備就緒時從默認分支創建新的命名分支，並在開發繼續默認情況下根據需要進行修復。