I've been working with Mercurial now for some time. When making (private) changes to some third party software, in the past I always created a separate named branch for these changes. When the upstream code updates, I simply merge it into my named branch.
Today I read about MQ (Mercurial Queues - chapters 12 and 13). I think I understood the concept behind MQ, so my question is:
Is there any advantage of MQ over (named) branches in Mercurial (for my scenario)?
名前付きブランチに対するMQの主な利点は次のとおりです。
パッチを修正できます。これにより、履歴を編集できるため、アップストリームコードの上にクリーンで論理的な一連のパッチを維持できます。パッチに誤りがあることに気付いた場合は、新しいコミットを行う代わりにパッチを更新します。
パッチの変更は、アップストリームで行われた変更から完全に分離されます。2つのブランチをマージすると、2つの開発ストリームが混在します。これにより、アップストリームブランチからの変更も確認せずに、行った変更を確認することが困難になります。
パッチ名は一時的なものです。パッチをhg qfinish適用すると、コミットにパッチ名の痕跡が残りません。したがって、最初にアップストリームリポジトリと調整しなくてもMQを使用できます。これは、アップストリームリポジトリがMQに気付くことはないためです。
マージを回避します。アップストリームからの最新のコードとマージする代わりに、適用したパッチをリベースします。これにより、より簡単な履歴が得られます。アップストリームからコードを見た後にすべてのパッチを作成したふりをしているため、履歴は明らかに偽物です。実際には、アップストリームと並行して作成し、後でパッチをアップストリームの先端に移動しました。
チェンジセットに永続的なブランチ名はありません。人々は時々、名前の付いた枝を使い捨てとして扱い、名前の付いた枝が歴史の中で固定されていることに気付いたときに動揺します。（パッチをプッシュする前に実際にブランチ名を設定できるhg branchので、この点はそれほど悪くありません。）
MQの欠点は次のとおりです。
それは学ぶための追加のツールです。それは強力ですが、それはまたあなたに足で自分自身を撃つより多くの機会を与えます。実行hg qdeleteするとパッチが実際に削除されるため、データを破棄できます。（これは問題ないと思いますが、Gitユーザーがメーリングリストに来てこれについて不満を言っています。）
他の人とのコラボレーションがはるかに難しくなります。リポジトリに変えて、リポジトリ間でパッチをプッシュ/プルすることはでき.hg/patchesますが、複数の開発者がいる場合、それを行うのは困難です。問題は、複数の人が同じパッチを更新すると、パッチをマージしてしまうことです。
チェンジセットに永続的なブランチ名はありません。名前付きブランチを正しく使用していて、安定した長期のブランチ名を使用している場合、MQを使用するとそれを見逃すことになります。
良い質問。場合によります。個人的にはmercurialの分岐システムが嫌いで、できるだけ避けようとしています(分岐の代わりにプッシュされたブックマークを使用しています)。
MQ は優れたツールであり、優れた機能と大きな落とし穴があります。pbranchの使用を検討することもできます。
MQ は、feature-x をプロジェクトに追加し、アップストリーム コードでパッチを更新するなど、プロジェクトのパッチ セットを作成および維持する必要がある場合に最適なツールです。
ブックマーク (または必要に応じてブランチ) は、上流のコードにマージする必要がある短い開発タスクに適しています。