mercurial での同時開発を管理するにはどうすればよいですか?

StackOverflow https://stackoverflow.com/questions/3719019

質問

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

まず第一に、私は同じプロジェクトの異なる変更について話しているので、サブリポジトリは禁止してください。

コードベースが hg リポジトリにあるとします。あなたが複雑な新機能 A に取り組み始めた後、信頼できるテスター (テスターはいますよね?) によって複雑なバグ B が報告されます。

B (の修正) が A に依存するとしても、それは自明のことです。ci A を入力してから ci B を入力するだけです。

私の質問は、彼らが独立したら（少なくとも今はそう思われる）、どうするかです。

次のような方法が考えられます。

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

1 と 2 は、 素晴らしいブログ by @Steve Losh からリンク 少し関連した質問.

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

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

4 はめまいを感じるかもしれませんが、これが最も強力で、柔軟でスケーラブルな方法です。私はデフォルトします hg qinit と -c 進行中のパッチにマークを付けてプッシュ/プルしたいためですが、MQ リポジトリでも分岐できることを理解するには、概念的な飛躍が必要です。手順は次のとおりです (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 はほとんど時代遅れになります。Steve Losh の洗練された説明をご覧ください。 ここ.

役に立ちましたか？

解決 2

私が質問に挙げたもの以上の選択肢はないようです。それで、彼らは再びここにいます。

  1. プロジェクトごとに 1 つのクローンを使用します。
    • 長所:完全に分離されているため、プロジェクトを切り替えるときに再構築する必要はありません。
    • 短所:ツールチェーンは 2 つのクローン間で切り替える必要があります。
  2. 同じリポジトリ内で匿名または名前付きブランチ、またはブックマークを使用します。
    • 長所:標準的な hg (または任意の DVCS) の実践。クリーンでクリアな。
    • 短所:切り替える前にコミットし、切り替え後にリビルドする必要があります。
  3. プロジェクトごとに 1 つのパッチ (または複数の連続したパッチ) で MQ を使用します。
    • 長所:シンプルで簡単。
    • 短所:しなければならない qrefresh 切り替え前と再構築後。プロジェクトが直交していない場合、扱いが難しく危険です。
  4. 1 つの MQ ブランチを使用する (または qqueue 1.6 以降) プロジェクトごとに。
    • 長所:非常に柔軟でスケーラブル (同時プロジェクトの数に対して)
    • 短所:しなければならない qrefresh そして qcommit 切り替え前と再構築後。複雑な気持ちになる。

いつものように、特効薬はないので、その仕事に適したものを選んでください。

(更新) MQ に興味がある人にとっては、通常のブランチ (#2 + #3) 上で MQ を使用するのが、おそらく最も一般的で望ましい方法でしょう。

2 つのブランチ (たとえば、次のリリースと現在のリリース) にベースラインを持つ 2 つの同時プロジェクトがある場合、次のようにそれらの間を行き来するのは簡単です。

hg qnew; {coding}; hg qrefresh; {repeat}
hg qfinish -a
hg update -r <branch/bookmark/rev>
hg qimport -r <rev>; {repeat}

最後のステップとして、 qimport を追加する必要があります -a 変更セットの行を一度にインポートするオプション。願っています マイスター・ガイスラー これに気づきました:)

他のヒント

Mercurial がその仕事をできるようにするため、私は常に名前付きブランチを使用します。プロジェクト履歴を保存し、ソース コードにどの変更をどのような順序で加えたのかを覚えておくためです。私の作業スタイルを考慮すると、ディスク上に 1 つのクローンを置くか 2 つのクローンを置くかは、一般に簡単です。少なくとも次のようになります。

  1. プロジェクトにはビルド プロセスが不足しているので、ソース コードから直接テストして実行できますか?そうなると、クローンを 1 つだけ持ちたくなるでしょう。 hg up 別のブランチで作業する必要があるときに行ったり来たりする必要があります。

  2. ただし、buildout、virtualenv、またはその他の構築される構造があり、それが 2 つのブランチ間で分岐する可能性がある場合は、 hg up 特にサンプル データベースのセットアップなどが関係する場合、ビルド プロセスが再実行されるのを待つのは大きな苦痛になる可能性があります。その場合、私は間違いなく 2 つのクローンを使用します。1 つはトランクの先端に配置され、もう 1 つは緊急機能ブランチの先端に配置されます。

したがって、問題は、機能 A の作業を中止して、独立した機能 B を開始するように指示された時点で、次のような代替オプションがあるかどうかです。mercurial での同時開発を管理するにはどうすればよいですか?

スレッド化されたコードを記述するのと同じ方法で、同時実行性を削除した問題を見てみましょう。与えられた問題を解決するための簡単なワークフローを定義し、それを各問題に適用します。作業が完了したら、Mercurial も作業に参加します。したがって、プログラマー A は機能 A に取り組みます。プログラマー B は機能 B に取り組みます。どちらもたまたまあなたであるだけです。(マルチコアの頭脳があれば:)

Mercurial がその仕事をできるようにするため、私は常に名前付きブランチを使用します。プロジェクト履歴を保存し、ソース コードにどの変更をどのような順序で加えたのかを覚えておくためです。

私もブランドンの意見に同意しますが、彼は機能 A がテストされていないことを見落としていたのではないでしょうか?最悪の場合、コードはコンパイルされて単体テストに合格します。 ただし、一部のメソッドは以前の要件を実装し、一部のメソッドは新しい要件を実装します。 前回のチェックインとの差分は、機能 A の軌道に戻るために使用するツールです。

機能 A のコードは、通常チェックインする時点にありますか? 機能 A から機能 B の作業に切り替えることは、コードをヘッドまたはブランチにコミットする理由にはなりません。コンパイルしてテストに合格したコードのみをチェックインします。 その理由は、プログラマ C が機能 C を開始する必要がある場合、このブランチを新たにチェックアウトすることは開始するのに最適な場所ではなくなったからです。 ブランチヘッドを健全に保つことは、より信頼性の高いバグ修正で迅速に対応できることを意味します。

目標は、(テストおよび検証された) コードを実行することなので、すべてのコードが最終的に (開発ブランチとレガシー ブランチの) 先頭にマージされるようにする必要があります。私が言いたいのは、分岐が非効率的に使用されているのを見てきたということです。コードが古くなって使用されなくなると、マージは元の問題よりも難しくなります。

私にとって意味があるのは選択肢 1 だけです。一般的に：

  1. 他の人に見られる前に、自分のコードが機能することを確認する必要があります。
  2. 枝よりも頭を優先します。
  3. 他の誰かが問題を発見した場合は、ブランチしてチェックインします。
  4. 自動化システムまたはテスターがコードのみを必要とする場合に分岐します。
  5. 問題に取り組んでいるチームの一員である場合は、分岐します。それを頭と考えてください。1-4 を参照してください。

構成ファイルを除き、ビルド プロセスはチェックアウトと単一のビルド コマンドである必要があります。クローンを切り替えることは、新しいプログラマがプロジェクトに参加することよりも難しいことではありません。(私のプロジェクトにはここで少し作業が必要であることを認めます。)

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top