4

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

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

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

4

5 に答える 5

7

Mercurial wiki には、ユースケースに関する適切なセクションがあります。

要約すれば：

  1. 作業コピーの現在の状態を保存して、後で簡単に元に戻せるようにする
  2. 「もつれた作業コピー」の防止 - 変更の途中で他の何かを変更したい場合
  3. 変更可能で再配置可能なコミットを提供して、プッシュする直前に「履歴」を確認できるようにします。
于 2010-11-05T11:00:08.717 に答える
4

Bitbucket でパッチ キューを作成すると、パッチ キューの一般的な用途の一部が右側のペインに一覧表示されます。彼らの説明はとてもよく、あなたの質問に直接答えます。そこからの引用は以下。

パッチ キューは次の場合に適しています。

  • アップストリーム レビューに提出する機能の開発

    パッチ キュー内のパッチは変更できるため、履歴を追跡しながら機能を開発する理想的な方法を提供すると同時に、フィードバックを簡単に組み込むことができます。

  • 新しい機能を追加して実験する

    パッチ キューはプロジェクトの履歴を乱雑にしないので、失敗したエクスカーションでプロジェクトの履歴を乱雑にすることなく、アイデアをすばやく試してバージョン管理を維持する方法として安全に使用できます。実験を続けることにした場合は、パッチ キューを従来の Mercurial コミットのセットに簡単に変えることができます。

  • 別のプロジェクトのプライベート カスタマイズの維持

    パッチ キューはプロジェクトの公式の変更ログの一部ではないため、アップストリーム プロジェクトのプライベートなカスタマイズを維持するのに理想的です。たとえば、プログラムと会社のワークフローとの統合を改善するパッチ キューを維持する場合があります。

パッチ キューは適していません。

  • 長期ブランチ

    パッチ キューは非常に揮発性が高いため、ソース コードの長期的な履歴を追跡するには不十分です。このため、製品リリースに対応するものなど、実行時間の長いブランチは、リポジトリまたは名前付きブランチに保持する必要があります。

  • グループ開発

    パッチ キューはマージ履歴を追跡しないため、特定の機能セットがいつリポジトリにマージされたかを実際に確認したいグループ開発には適していません。疑問がある場合は、従来のフォークに固執する必要がありますが、パッチ キューの機能を習得すると、ワークフローが非常に柔軟になり、コラボレーション機能が大幅に強化されます。

于 2011-02-16T12:49:57.060 に答える
4

これには Mercurial パッチは必要ありません。プルするときにコミットされていない未解決の変更がある場合、それらはヒントにマージされます。

例：

C:\>hg init db
C:\>cd db
C:\db>echo >file1
C:\db>echo >file2
C:\db>echo >file3
C:\db>hg ci -Am codebase          # Create a code base with 3 files.
adding file1
adding file2
adding file3
C:\db>echo a change >>file2       # Outstanding change to file2.
C:\db>hg st
M file2

この時点で、データベースのクローンを作成し、プルできる変更をコミットします。

C:\db>hg clone . \db2
updating to branch default
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
C:\db>cd \db2
C:\db2>echo a change >>file3
C:\db2>hg ci -m "file3 change"    # Commit a change to file3.

元のデータベースに戻る...

C:\db2>cd \db
C:\db>hg st                       # Still have uncommitted change
M file2
C:\db>hg pull \db2
pulling from \db2
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
(run 'hg update' to get a working copy)
C:\db>hg st                       # We have the new history, but haven't updated.
M file2                           # file2 has uncommitted change.
C:\db>type file3                  # file3 is unchanged. 
ECHO is on.
C:\db>hg update
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
C:\db>hg st                       # We've updated, and file2 *still* has
M file2                           #    uncommitted change.
C:\db>type file2
ECHO is on.
a change
C:\db>type file3                  # But file3 now has committed change
ECHO is on.                       #    that was pulled.
a change

したがって、コミットされていない変更であっても、プルして更新するだけでよいというのが教訓です。マージの競合がある場合、通常のマージ動作も発生します。

パッチのエクスポートhg export <rev>では、レビュー用にパッチがエクスポートされます。

于 2010-11-05T07:15:01.920 に答える
1

MQ は、並行開発を管理するための優れたツールです。私自身の答えからの露骨な自己盗作と自己宣伝：

3 プロジェクトごとに 1 つのパッチ (または複数の連続したパッチ) で MQ を使用します。

  • 長所：シンプルで簡単。
  • 短所: 切り替える前に qrefresh し、後で再構築する必要があります。プロジェクトが直交していない場合、トリッキーで危険です。

4 プロジェクトごとに 1 つの MQ ブランチを使用します。

  • 長所: 非常に柔軟でスケーラブル (並行プロジェクトの数に対して)
  • 短所: 切り替える前に qrefresh と qcommit を実行し、後で再構築する必要があります。複雑に感じます。
于 2010-11-05T17:52:16.597 に答える