私はしばらくMercurialで作業してきました。いくつかのサードパーティのソフトウェアに（私的な）変更を加えるとき、私はいつもこれらの変更のために別々の名前付きブランチを作成しました。アップストリームコードが更新されると、私は単にそれを自分の名前付きブランチにマージします。MQとMercurialのブランチ
今日私はMQ（Mercurial Queues - チャプター12と13）について読んでいます。
私のシナリオでは、MercurialのMQ over（named）ブランチの利点はありますか？
という名前の枝の上にMQの主な利点は以下のとおりです。
あなたのパッチを修正することができます。これにより履歴を編集できるので、上流のコードの上に清潔で論理的な一連のパッチを維持することができます。パッチに間違いがある場合は、新しいコミットを行う代わりにパッチを更新します。
パッチの変更は、アップストリームの変更と完全に分離されます。 2つのブランチをマージすると、2つの開発ストリームが混在します。これにより、アップストリームブランチからの変更を見ることなく、変更を確認することが困難になります。
パッチ名は一時的です。 hg qfinish適用パッチを適用すると、コミットに残ったパッチ名のトレースはありません。したがって、MQを気にすることはないので、上流のリポジトリと最初に調整することなくMQを使用することができます。
マージは避けてください。アップストリームの最新のコードとマージする代わりに、適用されたパッチrebaseを入手してください。これにより、より簡単な履歴が得られます。 Infactはあなたが上流のと並行して、それを作ったと、後では、上流の先端にあなたのパッチを移動したとき - あなたは、上流からのコードを見した後、すべてのパッチをたことふりをするので歴史は明らかに偽物です。
チェンジセットに永続的なブランチ名がありません。人々は時々treat named branches as disposableと呼ばれ、名前付き支店が歴史の中で修正されていることを知ったときに動揺します。 （あなたが実際にこの点はそれほど悪いわけではないので、パッチをプッシュする前にhg branchと支店名を設定することができます。）MQの
短所は以下のとおりです。
それは学ぶための余分なツールです。パワフルですが、足で自分を撃つ機会が増えます。 hg qdeleteを実行すると、のパッチが削除され、データを破棄することができます。 （私はこれは問題ないと思いますが、Gitのユーザーがメーリングリストに来てこのことについて不平を言ってきました）
他人との共同作業がずっと難しくなっています。 はになります。.hg/patchesをリポジトリに入れて、リポジトリ間でパッチをプッシュ/プルすることはできますが、単一のデベロッパー以上の人はパッチを作成するのが難しいです。問題は、複数の人が同じパッチをリフレッシュすると、パッチをマージすることになります。
チェンジセットに永続的なブランチ名がありません。名前付きブランチを正しく使用していて、安定した長期ブランチ名を使用している場合は、MQを使用するときにそれを忘れるでしょう。
良い質問です。場合によります。個人的に私は水銀分枝システムを嫌いです。できれば分かりやすいようにします（分枝の代わりにプッシュブックマークを使用）。
MQは大きな力と大きな落とし穴を持つ素晴らしいツールです。 pbranchを使用して検討することもできます。
MQは、プロジェクトにfeature-xを追加したり、上流のコードでパッチを更新したりするなど、プロジェクトのパッチセットを作成して維持する必要がある場合に最適なツールです。
ブックマーク（または好きな場合はブランチ）は、上流のコードにマージする必要のある短期開発タスクに適しています。
リベースしても同じ結果が得られます。 –
@LaurensHolst：ああ、そうです。私は、MQ *がどのようにパッチを再構築するかにもっと焦点を当てていました。つまり、MQではマージはできません。答えを少し広げてみましょう。 –
MQCollab拡張機能は、MQパッチによるコラボレーションを実現します。*本当に素敵です。* –