Mercurial とコードレビュー。良いワークフロー?

Question

私は、中央リポジトリに Mercurial を使用する小規模な分散チームに所属しています。私たちはそれぞれ、ssh 経由で自分の Linux ボックスにクローンを作成します。私たちの目的は、変更を中央リポジトリにプッシュする前にお互いの作業をレビューし、中央のチップをクリーンな状態に保つことです。異なる Linux ボックス上の開発者間でコードを共有する良い方法は何ですか?Mercurial を初めて使用します。私が考えることができる選択肢は（経験ではなく読書を通じて）次のとおりです。

1:作成者はすべてのローカル変更をコミットし、中央のヒントを使用して作業クローンを更新します。バンドルに含めるローカル Rev を指定する方法がある場合、著者は hg バンドルを使用します。(実験により、中央が知らない以前のローカルコミットがあったとしても、「バンドル」はコミットされていない変更のみを取得することがわかりました) 作成者はバンドルファイルをレビュー担当者に渡します。レビューアーは、中央のチップから新しいクリーンなクローンを作成し、バンドルをそのクローンにインポートします。または、

2:作成者とレビュー担当者の両方が中央のチップから取得した後、作成者はパッチを使用し、レビュー担当者はパッチをインポートします。または、

3:著者が査読者にプッシュするか、査読者が著者からプルするか（正確にはどのようにするのでしょうか？）私が読んだ内容は、元の提供リポジトリへのプッシュとプル、および/または異なる Linux ボックス間ではなく同じボックス上でのプッシュとプルについてのみです。)

4:中央にプッシュする前にコードを確認することは忘れてください。タグを使用してレビュー済みかどうかを識別し、Hudson (すでに動作しています) を使用して最新の安全なビルドにタグを付けてプッシュし、チーム メンバーがどれからプルするかを判断できるようにします。

あなたのチームが Mercurial を使用していてコードレビューを行っている場合、レビュー担当者に変更内容を確認してもらうにはどうすればよいでしょうか?

Answer 1

これらのほとんどは可能であり、一部は他のものよりも退屈です。

1. 中央リポジトリの先端を指定することで、バンドルを使用できます。 --base:
   hg bundle --base 4a3b2c1d review.bundle
2. バンドルを使用するだけでもあります。そうすれば、Changesetデータも含まれています。
3. 共通の祖先を持つ任意のリポジトリにプッシュ（およびプル）することができます。あなたがあなたの同僚の一人から引っ張りたいなら、彼らはただ走る必要があります hg serve 彼らのマシン上で、あなたは引っ張ることができます。
4. これも機能しますが、複数のヘッドを維持し、マージに注意する必要があります。そうでない場合は、リビューされていない変更セットに加えて安定した変更を簡単にベースにすることができます。これにより、後で再確認されていない変更セットを修正する必要がある場合は、元に戻すのが難しくなります。

提示したオプションのうち、＃1と＃3は、お互いの箱に到達できるかどうかに応じて、おそらく最も簡単です。

関連メモ：これは私の同僚と私が開発を始めた質問です 窯, 、私たちの（フォグクリークの）水銀ホスティングおよびコードレビューツール。私たちの計画と最初のプロトタイプは、複数のリポジトリ、1つの「中央」リポジトリ、および多数の「レビュー」リポジトリを維持します。レビュープロセスは、セントラルリポジトリをサーバー上のレビューリポジトリにクローニングし、2つの間に完全なレポジを実行し、DIFFを取得および表示するためのシンプルなWebインターフェイスを使用して開始されます。

私たちはそのワークフローをかなり進化させましたが、一般的なアイデアは、再確認されていない変更をプッシュするブランチレポを持っていることと、それらを中央リポジトリに押し込む前にそれらをレビューするインターフェイスを持っていることはまだ同じです。ここで宣伝したくありませんが、お勧めします 試してみてください.

Answer 2

この質問に対する半分の答えが使用されています 審査委員会 と 水銀拡張. 。次のコマンドを発行することにより、レビューのために特定の改訂をプッシュできます

HG PostStreviewヒント

Answer 3

5 番目のオプションを追加します。すべての開発作業を名前付きブランチで実行します (できればタスクごとに 1 つ)。動作状態かどうかに関係なく、「開発」という名前のブランチに何でもコミットできるようにします。

中央リポジトリにプッシュし、レビュー担当者にブランチをプルしてもらいます。ブランチでレビューを実行します。

レビューに合格したら、開発作業を適切な機能ブランチにマージします。

このワークフローは (私にとっては) 驚くほど人気が​​ありませんが、多くの利点があります。

1. すべての作業がコミットされます。コミットする前にレビューが完了するまで待つ必要はありません。

2. 間違ったバージョンを構築することはありません。ビルドはフィーチャー ブランチからのみ行うことができます。

3. 進行中の作業は他の開発者に干渉しません。

4. 開発ブランチからは、最新の変更を確認できます (例:レビュー コメントに対応する変更セット)、ブランチ ポイントとの比較、または最新の機能ブランチとの比較 - これらすべてが有益な情報を提供します。