問題タブ [mercurial-queue]

Mercurialリポジトリに保持されているコードベースで、さまざまなビルドテストを実行する必要があります。これらのテストは共通ファイルのセットを変更し、異なるマシンで並行して実行したいので、同じリポジトリでこれらのテストを連続して実行したくありません。また、すべてのテストを実行した後、それらのテスト作業領域からの最新のテスト結果にアクセスしたいと思います。現在、マスターリポジトリのクローンを数十回作成しており、各クローンで1つの異なるテストを実行しています。各テストを実行する前に、最新のクリーンな状態でテストを開始するために、プル/更新/パージの準備シーケンスを実行します。それは私にとって良いことです。

また、コミットする前に上記のようにすべてのクローンでテストするmq拡張機能を使用して新しい変更を準備しています。いくつかの準備ができている候補mqパッチをテストするために、テストクローンで使用できるようにそれらを展開/同期し、テストを実行する前にガードを使用してテストの準備ができているパッチを適用したいと思います。

誰かが以前にこの同期を行ったことがありますか？それを行う最も簡単な方法は何ですか？そのためにバージョン管理されたmqパッチが必要ですか？

Mercurial を使用して、使用しているソフトウェアのバニラ インストールに加えられた変更をキャプチャしたいと考えています。ソフトウェアをアップグレードするたびに、さまざまな構成ファイルを手動で編集し、現在のバージョンのソフトウェアで使用するサードパーティ ライブラリを追加する必要があります。構成ファイルの変更に対するパッチの作成は問題ありませんが、サードパーティのライブラリ (バイナリ) を Mercurial パッチに追加するにはどうすればよいですか? それは可能ですか？

パッチを作成できるようにしたい Web アプリケーションがあります。具体的には、Web サーバーで特定の機能を有効にするためのパッチを作成したいと考えています。

私がやりたいことは、パッチを個別に (qpush -move を使用して) またはすべて一緒に (qpush -a) 適用できるように、このファイルに加える必要がある個々の変更ごとにパッチを保存することです。

最初に、クリーン バージョンのファイルで次のことを試しました。

次に、ファイルの最初の行を次のように変更しました。

その後、パッチを更新しました

パッチをポップして、クリーンベースからの 2 番目の変更の作業を開始しました

ファイルの最初の行を次のように変更しました

その後、パッチを更新しました

その後、古いパッチを qpush しようとしたところ、適用に失敗しました。次に、最初にベースパッチを作成するという別のアプローチを試しました。

、ファイルに以下を追加しました

、次に base.patch を更新します

次に、base.patch がまだ適用されている間に jmx の新しいパッチを作成します。

次のようにファイルを編集します。

パッチを更新してポップします。

ゼリー用の新しいパッチを作成します。

次のようにファイルを編集しました。

パッチを更新しました:

しかし、再び、新しく作成された jelly.patch の上に jmx.patch を qpush しようとすると、競合が発生しました。

Mercurial は期待どおりに動作していると思いますが、作成中のパッチを別の方法で構成して、個別に適用したり、拒否せずに組み合わせたりできるかどうか疑問に思っています

私は水銀キューを使用していますが、メッセージを a で設定するのhg qrefresh -m ...を忘れたり、実行前に確認するのを忘れたりしhg qfinishて、メッセージを受け取ることがありますpatch MyPatch finalized without changeset message。メッセージがない場合、qfinish を中止させる方法はありますか?

その後、これを修正する唯一の方法はhg strip、最後のリビジョンであるパッチを生成し、パッチを再適用してから、メッセージでコミットすることです。

これはベストプラクティスの質問であり、答えは「状況によって異なります」と予想されます。もっと現実世界のシナリオとワークフローを学びたいと思っています。

まず、同じプロジェクトのさまざまな変更について話しているので、サブレポは使用しないでください。

hgリポジトリにコードベースがあるとしましょう。複雑な新機能Aの作業を開始すると、信頼できるテスターから複雑なバグBが報告されます（テスターがいますよね？）。

B（の修正）がAに依存している場合、それは簡単です。単純にci A、次にciBです。

私の質問は、彼らが独立しているときに何をすべきかということです（または少なくとも今はそう思われます）。

私は次のように考えることができます：

1. Bには別のクローンを使用します。
2. 同じリポジトリで、匿名または名前付きのブランチ、またはブックマークを使用します。
3. MQを使用します（Aの上にBパッチを付けます）。
4. 分岐MQを使用します（後で説明します）。
5. 複数のMQを使用する（1.6以降）

1と2は、わずかに関連する質問からリンクされた@SteveLoshによる優れたブログでカバーされています。

1が他の選択肢よりも優れている点の1つは、ファイルが物理的に分離されて独立しているため、ある作業から別の作業に切り替えるときに再構築が不要なことです。したがって、たとえば、Aおよび/またはBがトライステートブール値を定義し、数千のCファイルにインクルードされているヘッダーファイルにアクセスする場合、これが実際に唯一の選択肢です（このようなレガシーコードを見たことがないことを教えてください）。ベース）。

3はおそらく（セットアップとオーバーヘッドの点で）最も簡単であり、Bが小さいか緊急の修正である場合は、AとBの順序を逆にすることができます。ただし、AとBが同じファイルにアクセスすると、注意が必要になる場合があります。AとBの変更が同じファイル内で直交している場合に適用できなかったパッチハンクを修正するのは簡単ですが、概念的にはまだ少し危険です。

4はめまいを起こす可能性がありますが、最も強力で柔軟性があり、スケーラブルな方法です。進行中のパッチにマークを付けてプッシュ/プルしたいので、デフォルトhg qinitでを使用しますが、MQリポジトリでも分岐できることを理解するには概念的な飛躍が必要です。-c手順は次のとおりです（mq = hg --mq）。

1. hg qnew bugA; Aに変更を加えます。hg qref
2. mq branch branchA; hg qci
3. hg qpop; mq up -rtip^
4. hg qnew bugB; Bに変更を加えます。hg qref
5. mq branch branchB; hg qci
6. Aに再度取り組むには：hg qpop; mq up branchA; hg qpush

非常に多くのステップを踏むのはおかしなことに思えます。仕事を切り替える必要があるときはいつでも、そうしなければなりませんhg qci; hg qpop; mq up <branch>; hg qpush。ただし、これを考慮してください。同じリポジトリに複数の名前付きリリースブランチがあり、それらすべてに対して同時に複数のプロジェクトとバグ修正に取り組む必要があります（この種の作業には保証されたボーナスを取得する方がよいでしょう）。他のアプローチではすぐに迷子になります。

今、私の仲間のhg愛好家、他の/より良い選択肢はありますか？

（更新）qqueue＃4はほとんど時代遅れになります。ここでSteveLoshのエレガントな説明を参照してください。

Mercurial でパッチを作成するプロセスは次のとおりです。

qnew でパッチを作成 -> 変更を加える -> パッチを更新

既に (コミットされていない) 変更を行っていて、それらをキューに追加したい場合はどうすればよいですか?

私は次の場合に水銀パッチを使用します:-

1. リモートリポジトリからプルする必要があり、コミットされていない未解決の変更がある場合。次に、パッチを作成して qpop し、リモート リポジトリからプルして、パッチを再度インポートします。
2. レビューボードにパッチをアップロードする必要があるとき。パッチを作成してアップロードするだけです。

他にどのように Mercurial パッチ キューを使用していますか? これは非常に強力な Mercurial 拡張機能であり、その可能性を最大限に活用できていないと感じています。

拡張機能のqrefreshコマンドはMQ私には意味がありません。私の仮定を説明します：

1. 特定のパッチを適用する必要があるリビジョンがわからない場合は、ほとんど価値がありません。リジェクトが何を意味するのかを理論的に知ることはできません。また、特定のリビジョンでリジェクトがなくても、リビジョン全体がコンパイルされるかどうかはわかりません。
2. パッチ キューにqrefresh特定のパッチを追加すると、実際にはキュー内の次のパッチの親が失われます。したがって、あなたの介入がなければ、この次のパッチは役に立たない/役に立たないかもしれません.
3. 次のパッチを修正するには.rej、ファイルを手動で編集するのではなく、マージすることをお勧めします。ツールが優れているという理由だけでなく、元qrefreshのパッチを使用していない場合は、より多くの情報が得qrefreshられ、パッチに加えた変更を意味のあるものにするために実際に必要な情報を失うことになります。

したがって、なぜこのコマンドを使用したいのかわかりません。

より良い代替手段は、すべてのパッチを適用してhg updateから、変更するパッチの親に適用し、次にhg revert作業ディレクトリを変更するパッチに適用することです。このパッチを変更し、新しいリビジョンにコミットしてから、他のすべてのパッチをこの新しいリビジョンにリベースします。

qrefresh単一のパッチのみを編集していない場合、いつ関連するのかわかりません。gitのアプローチ (ローカル ブランチにパッチを適用する) は、パッチ キューよりもはるかに理にかなっているようです。

私は正しいですか、リベースを使用したほうがよいですか? 見逃したものはありますか？

反応がなく視聴率が低いため、 kiln.se.comから移行しました

コードの変更に取り組んでいるときに、それ自体がサブリポジトリであるリポジトリ内の共有ライブラリ コードに対応する変更を加える必要がある場合があります。変更をコミットしたいときは、親リポジトリで行い、Mercurial はサブリポジトリで対応するコミットを行います。

しかし、私は最近、MQ を使用して自分自身の変更履歴をより適切に追跡し、実験の自由度を高め、大規模なリファクタリング作業をより安全に行えるようにしました。親リポジトリとサブリポジトリの両方で MQ を有効にしています。

上記のシナリオで、新規または既存の MQ パッチに「コミット」すると、サブレポが無視されると想定するのは正しいですか? これは私のテストで起こっているようです。これは、サブレポでパッチ キューを手動で管理する必要があるということですか? これはすぐに扱いにくくなります。

これがうまくいかない場合は、それで問題ありません。ワークフローを調整して、クロスレポ作業を行うときに MQ を回避できます。

更新:このスレッドによると、現時点では「サポートされていない」可能性があるようです: https://www.mercurial-scm.org/bts/issue2499

私は次のことを試しました：

1. サブレポの変更を手動でコミットしました。
2. サブリポジトリ コミットからのハッシュを使用して、親リポジトリの .hgsubstate ファイルを手動で更新しました。
3. 親リポジトリを qrefresh しようとしました。

アイデアは、手動で行う必要がある場合でも、親リポジトリからコミットを取得して、常に正しいサブレポ バージョンと同期できるようにすることでした。残念ながら、Mercurial はここで私を保護したいと考えているようで (そうあるべきです!)、qrefresh しようとすると次のように表示されます。

物事を「修正」するために、親リポジトリで hgfinish の後に空のコミットを行い、物事を同期させます。しかし...それはばかげているようで、コードの歴史を理解するのが難しくなります。

まあ、私は石器時代に戻って、サブリポジトリが関係するワークフローで MQ を使用するのをやめるだろうと思います。

リポジトリでMercurialQueuesを使用していて、それらのパッチをパッチリポジトリに配置しました。別の寄稿者が私のパッチキューのクローンを作成し、独自の変更を加えました。ここで、ローカルパッチリポジトリでそれらの変更をマージしたいと思います。

このマージを実行するための適切なワークフローを見つけようとしています。

• パッチリポジトリの履歴に寄稿者の変更セットを反映します
• 競合が発生した場合にユーザーのマージツールを呼び出します

最初は、パッチを直接マージしようとしました。これは非常に単純なケースでは問題ありませんが、パッチは行番号のコンテキストに依存しているため、多くのことが変更された場合はうまく機能しません。全体として、パッチの3方向の差分を調べるのは複雑すぎると思います。

もっと良い方法はありますか？