4

私は ClearCase ショップで働いており、CC はチームの作業をうまく統合していますが、私たちのコード レビュー プロセスでは、CC を使用して毎日の変更を追跡することはできません。CC ビューの上に hg リポジトリを作成すると、非常にうまく機能します。変更を追跡し、ファイル サーバーで簡単にバックアップを作成したり、人々の差分を作成したりできます。

これは、新しい CC ビューに移動して履歴を残さなければならないまでは、問題ありません。プルできるようになりたいです。以前の履歴が新しいビューに表示され、最新の変更セットとして表示されます。

4

3 に答える 3

3

ClearCaseを使用したことがないので、CCビューが何であるかは正確にはわかりませんが、ここで適切なベンダードロップの一般的な手法があります。アップストリーム（CC）バージョンを、たとえばリビジョン0としてチェックインします。 hgブランチvendorまたはあなたが望むものは何でも。デフォルトのブランチに戻し、ハックしてください。次に、最新のアップストリームバージョンに移動する場合vendorは、hgリポジトリを再度チェックアウトし、作業ディレクトリを新しいアップストリームに置き換え、実行しhg addremove（おそらく名前の--similarity変更を検出するオプションを使用して）、コミットして、現在のヒントとマージします。デフォルトのブランチに戻します。

于 2009-07-18T00:24:29.143 に答える
2

ブレンダンの答えを完成させるには、各ClearCaseビューが独自のパス（動的ビューの場合）またはローカルディレクトリ（スナップショットビューの場合）にあるため、次のことを行う必要があります。

  • あなたのhgリポジトリを移動します
  • 新しいCCビューの新しい構成仕様によって導入された変更を分離するために、hgリポジトリの新しいブランチをチェックアウトします（たとえば、UCMを使用している場合は、CCストリームの名前をhgブランチにミラーリングできます）
  • CCビューをMercurialリポジトリと同期する
于 2009-07-18T05:59:24.020 に答える
1

あなたが説明したのとほぼ同じ理由で、ClearCase静的ビュー内でGitを使用します-よりきめ細かい制御。

CC では、より新しい (ラベル付けされた) リリースの作業を開始し、構成仕様が適切に変更されると、Git はそれを通常の変更セットとして取得します。

Git は構成仕様について何も知らず、CC は .git ディレクトリについて何も知らないため、この魔法は正確に機能します。構成仕様が変更されると、変更されたファイルはすべてリロードされますが、.git ディレクトリには触れないため、Git は引き続きリポジトリを認識します。

Mercurial の使用経験はありませんが、起動していくつかのディレクトリとファイルを追加したところ、同じように動作するようです。

于 2009-07-19T12:15:03.467 に答える