Mercurial工作流程建議

Question

我對使用Mercurial提出了一些建議。

我們目前在中央服務器上使用CVS，並維護一個分支和幾個過去的版本分支。我們的工作流程是在HEAD上實施所有修補程序/新功能，然後在任何分支上創建發行版時，我們將有效地選擇需要包含在分支中的文件，並將分支標記移動到這些文件，然後去建立發佈（並標記它）。

我想在Mercurial中實現類似的工作流程。但是，我不確定是否可以從默認分支中選擇特定的修訂（更改集）並將其應用到我的發佈分支之一。我所看到的是人們將修補程序應用於其分支機構，然後將這些修補程序拉入默認分支。有沒有一種方法可以像上面描述的那樣使用Mercurial來模仿我們的CVS工作流程？

Answer 1

這很大程度上取決於你的'過去的版本分支'實際上是什麼，但我認爲你應該應該遷移時採用不同的工作流程。

想像合併河流合併分支：合併之後，合併分支的所有東西都在另一箇中。這就是爲什麼如果你想實現一個最終應該在多個分支中的功能，建議的方法是在其中一個分支中實現它，然後將它合併到其他分支中。理解源代碼分支中的所有內容都將在目標分支中結束，而不僅僅是您實現的功能，這一點非常重要。

因此，過去的版本分支形成matryoshka doll是合理的。例如，您有三個長期分支：1.x,2.x和default。 1.x中的所有功能也存在於2.x和default中，2.x中的所有功能也存在於default中。 （這裏，default是您的下一個主要版本的一個階段，你創建一個新的分支3.x當您鬆開V3.0）

所以，如果你想使一個新功能在1.x，你實現它那裏，然後做兩個合併：1.x分成2.x，然後2.x分成default（這是轉發端口）。如果您嘗試以相反方式執行此操作，則在default（即回移）中，您將無法合併default到1.x或2.x，因爲default有許多其他不應該出現的內容在舊版本中。很難逆流，所以你必須將必要的修改移植回1.x和2.x，這很可能不會很乾淨地應用，而且你基本上都是通過Mercurial可以爲你做的事情做些事情。

您可以查看Python存儲庫的佈局，在dev guide中進行了解釋。

Answer 2

根據我的經驗以及我對集體分佈式版本控制用戶體驗的理解，問題在於櫻桃挑選變更集（實際上始終是）合併衝突的處方。本質上，通過嘗試對最新代碼實施更改並將它們「回溯」到較舊的代碼，你迫使自己不得不一遍又一遍地重做相同的合併。

想象一下，您正在維護三個版本的Head，Head-1和Head-2。在Head-1中，您執行了一次重大的重構更改。現在，您在Head中實現三個新功能，並將其包含在Head-1和Head-2中。由於Head和Head-1都具有相同的大重構，所以將新特徵合併到Head-1中並不會那麼複雜。但是，爲了合併Head-2中的新功能，您可能必須解決所有三個功能中完全相同的合併衝突，才能解決主要的重構問題。

事實是，您可能已經這樣做了 - 您只是沒有意識到這一點，因爲CVS並沒有幫助您在另一個方向進行合併。像Mercurial和Git這樣的新版本控制系統可以使「前進」方向合併得更加容易。

因此，不是在頭部的Mercurial中實現這三個特徵，而是在頭部2中實施更改會更好。由於合併信息已經在圖模型中被捕獲，所以最有可能合併到Head-1然後Head將很容易。

我並不是說你要求的東西無法完成 - 你可以使用諸如移植擴展之類的東西來實現你的模型 - 你只是不會利用Mercurial的優秀合併能力如果你這樣做，你會爲自己和你的團隊做更多的工作。