MQ vs.Mercurial のブランチ

Question

私はしばらくの間 Mercurial と協力してきました。一部のサードパーティ ソフトウェアに (プライベート) 変更を加えるとき、私は以前は常に、これらの変更用に別の名前付きブランチを作成していました。上流のコードが更新されると、それを自分の名前付きブランチにマージするだけです。

今日は MQ (Mercurial Queues - 章) について読みました。 12 そして 13）。MQ の背後にある概念は理解できたと思うので、私の質問は次のとおりです。

(私のシナリオの場合) Mercurial の (名前付き) ブランチに比べて MQ に利点はありますか?

Answer 1

名前付きブランチに対する MQ の主な利点は次のとおりです。

• パッチを修正できます。これにより履歴を編集できるため、上流のコード上にクリーンで論理的な一連のパッチを維持できます。パッチの間違いに気づいた場合は、新しいコミットを作成する代わりにパッチを更新します。

• パッチ内の変更は、アップストリームで行われた変更から明確に分離されます。2 つのブランチをマージすると、2 つの開発ストリームが混合されます。このため、上流ブランチからの変更も確認せずに、行った変更を確認することが困難になります。

• パッチ名は一時的なものです。あなたが hg qfinish 適用されたパッチの場合、コミットにはパッチ名の痕跡が残りません。したがって、上流のリポジトリは MQ に気付かないため、最初に上流のリポジトリと調整しなくても MQ を使用できます。

• マージを避けます。アップストリームからの最新のコードとマージする代わりに、 リベース 適用したパッチ。これにより、より簡単な履歴が得られます。すべてのパッチを自分で作成したふりをしているので、履歴は明らかに偽物です 後 アップストリームからコードを確認する — 実際にはアップストリーム以降と並行してコードを作成した場合 移動しました パッチを上流の先端に追加します。

• 変更セットに永続的なブランチ名がありません。人は時々 名前付きブランチを使い捨てとして扱う そして、名前付きのブランチが歴史の中で固定されていることを知ると動揺します。(実際にはブランチ名を設定できます) hg branch パッチをプッシュする前なので、この点はそれほど悪くありません。)

MQ の欠点は次のとおりです。

• それは学ぶための追加のツールです。それは強力ですが、同時に自分の足を撃つ機会も増えます。ランニング hg qdelete 本当に 消去 パッチを適用するとデータを破棄できます。(これで問題ないと思いますが、メーリングリストにこれについて苦情を言ってくる Git ユーザーがいました。)

• 他の人と協力することがはるかに困難になります。あなた できる 振り向く .hg/patches をリポジトリに追加し、リポジトリ間でパッチをプッシュ/プルしますが、複数の開発者がいる場合、それを行うのは困難です。問題は、複数の人が同じパッチを更新すると、パッチがマージされてしまうことです。

• 変更セットに永続的なブランチ名がありません。名前付きブランチを正しく使用し、安定した長期ブランチ名を使用している場合、MQ を使用するときにそれを見逃すことになります。

Answer 2

良い質問。場合によります。個人的に私はMercurialの分岐システムを嫌う、そして私はできるときにそれを避けようとします（ブランチの代わりにプッシュされたブックマークを使用して）。

MQは素晴らしい力と素晴らしい落とし穴がある素晴らしいツールです。 pbranch を使用することもできます。

MQはプロジェクトのパッチセットを作成して維持する必要がある場合、Project-XにProject-Xを追加し、アップストリームコードでパッチを更新する必要がある場合は素晴らしいツールです。

ブックマーク（または好きな場合）は、アップストリームコードにマージする必要がある短い開発タスクに適しています。