MQ與Mercurial中的分支機構

Question

我一直在使用Mercurial一段時間。在對某些第三方軟件進行（私有）更改時，以前我總是爲這些更改創建一個單獨的命名分支。當上遊代碼更新時，我只是將它合併到我的命名分支中。

今天我讀了關於MQ（Mercurial Queues - 章節12和13）。我認爲我理解MQ背後的概念，所以我的問題是：

在Mercurial（針對我的場景）中，MQ比命名分支有MQ優勢嗎？

Answer 1

MQ的通過命名分支機構的主要優點是：

• 你可以修改你的補丁。這使您可以編輯歷史記錄，因此您可以在上游代碼之上維護一系列乾淨而合乎邏輯的修補程序：如果您發現修補程序中存在錯誤，則刷新修補程序而不是進行新的提交。

• 補丁中的更改將與上游所做的更改完全分離。當你合併兩個分支時，你混合了兩個發展流。這使得很難看到你所做的改變，而沒有看到來自上游分支的改變。

• 補丁名稱是暫時的。當您應用修補程序hg qfinish時，提交中沒有保留修補程序名稱的痕跡。因此，您可以使用MQ，而無需首先與上游存儲庫協調，因爲它們永遠不會注意到MQ。

• 您避免合併。而不是合併來自上游的最新代碼，而是您應用的修補程序。這給你一個更簡單的歷史。歷史顯然是假的，因爲你假裝你在之後看到上游的代碼 - 當你實現與上游並行時，並且後來將移動到上游的頂端時，你做了所有補丁。

• 您在變更集中沒有永久分支名稱。人們有時候會遇到treat named branches as disposable，當他們意識到命名分支在歷史中是固定的時候就會感到不安。 （你可以用hg branch推補丁所以這點並沒有那麼糟糕之前實際設置分支名稱。）MQ的

缺點是：

• 這是學習額外的工具。它很強大，但它也讓你有更多的機會在腳下自我射擊。運行hg qdelete會真的刪除的補丁，所以你可以扔掉數據。 （我認爲這很好，但是我們有一個Git用戶來到我們的郵件列表中抱怨這個）。

• 你讓它更難與他人合作。您可以可以將.hg/patches轉換爲存儲庫並在存儲庫之間推送/拉出修補程序，但如果您不僅僅是單個開發人員，則很難做到這一點。問題是，如果多個人刷新相同的補丁，則最終會合並補丁。

• 您在變更集中沒有永久分支名稱。如果您正確使用命名分支並使用穩定的長期分支名稱，那麼在使用MQ時您將錯過這一點。

Answer 2

好問題。這取決於。我個人不喜歡mercurial分支系統，我儘量避免它（使用推送書籤而不是分支）。

MQ是一個偉大的工具，具有強大的功能和巨大的陷阱。您也可以考慮使用pbranch。

如果您需要爲項目生成和維護補丁集，比如向項目中添加feature-x並使用上游代碼更新補丁，MQ是一個很好的工具。

書籤（或分支機構，如果您喜歡的話）適合需要合併到上游代碼的短期開發任務。