0

NS-3というプロジェクトで何か作業をしようとしていますが、私の問題はプロジェクト固有のものではないので、ここと関連するメーリングリストに質問したいと思いました。

基本的に、その時点で最新のプロジェクトコードのコピーが作成され、そのコードで新しいリポジトリが作成されました。作業は「フォーク」バージョンとトランクの両方で行われました。

したがって、フォークされたソース、cd in、およびhg pull <latest-dev>、のクローンhg mergeを作成しました。完全なマージではありませんでしたが、マージできない変更はすべて1つのライブラリの変更に関連していたため、（理論的には）簡単に修正できました。当然、この楽観的な試みは構築に失敗しました。

ここからどこに行くのか完全にはわかりません。DCVSは初めてですので、どうぞ。5歳向けのアイデア！

フォークされたバージョンのどのチェンジセットが、別々であるが関連するリポジトリであるため、dev-trunkに対して最後にマージされたかを確認するにはどうすればよいですか？

4

2 に答える 2

3

クローンではなくコピーから始めた場合:

これが起こった場合：

  1. プロジェクトが存在します
  2. プロジェクトのコピー（クローンではない）が作成されます
  3. hg init別々のコピーごとに実行され、2 つの無関係なリポジトリが作成されます
  4. 作業は両方のコピーで行われます

次に、それらをマージするには、2 つの無関係なリポジトリの最新でこれを行います。

  1. hg update 0、リポジトリを最初の時点 (最後に他のリポジトリと同一に見えた時点) に戻します。
  2. 他のリポジトリから作業ディレクトリの内容をコピーします
  3. hg commit、新しい頭を作成します
  4. hg merge、2 つのヘッドをマージし、マージ プロセスに役立つベースリビジョンも提供します。

重要なのは、可能であれば基本リビジョンを含めることです。CVS と SVN にない DVCS システムの利点は、すべてのマージが 2 つのヘッドと最新の共通の祖先の間の 3 方向のマージであるということです。2 つのリポジトリが同じように見える最後のポイント (コピーのリビジョン 0) から新しいヘッドを作成することによって、その共通の祖先を偽造すると、基本リビジョンがシミュレートされます。

于 2012-04-22T02:29:49.570 に答える
3

コピーではなくクローンから始めた場合

これは典型的な DVCS のケースであり、多くのことを行う必要はありません。クローンの 1 つに移動し、もう 1 つのクローンhg pullからhg merge. マージに入力が必要な場合は、hg resolveそれを提供するために使用し、完了したらhg commit.

この時点でコードがビルド/実行されていない場合は、デバッグを開始する必要があります。コンパイルされない行の近くで何が行われていたかを確認するために使用hg blameし、何が行われていて、どのように作業するかを調べてみてください。

マージ プロセスは、頻繁に行うほど簡単になります。毎月ではなく、毎日アップストリームの変更を取り込みます。

GraphLog拡張機能を有効にして、hg log -Gコマンドを使用して、開発の 2 つのラインが分岐したポイントを確認できますが、最終的にはマージは開発であり、他のソフトウェアの欠陥と同様に、ビルド以外のマージにアプローチする必要があります。 .

于 2012-04-22T02:36:55.737 に答える