12

ソースツリーとその履歴だけが必要です。今のところ、要件や問題については気にしません。コマンドラインを少し試して、トランクといくつかの開発パスの変更パッケージのリストを取得できるかどうかを確認しました。すべての変更パッケージの差分を抽出し、それを使用してgitでの最初のコミット以降のすべての変更を再生できるはずだと思いました。このようなもの：

  1. 最初のコミットを取得し、それをgitに追加します
  2. 次のCPを取得
  3. CPの差分を取得
  4. gitの作業ディレクトリにdiffを適用します
  5. gitに変更を追加してコミットする
  6. 最後のCPまで（2.）で繰り返します

変更パッケージをチェックポイントに置き換えることもできます（私にとっては十分でしょう）。

より簡単な方法は、CPをチェックアウトし、gitに追加/コミットすることです。ただし、追加、削除、移動、名前の変更操作を追跡できなくなります。

「sidiff」から統一されたdiffを取得する方法を知っている人はいますか？それはすでに大いに役立つでしょう。

何か案は？

Edit2：
実際に移行を行った方法を示す回答を追加しました...

4

5 に答える 5

10

自分の時間に書いたわけではないので、実際に書いたプログラムを投稿することはできません。しかし、私はそれをした方法を投稿することができます。どのスクリプト言語でも簡単にやり直せるはずです。私が作成したツールは、一度に 1 つのブランチのみを移行しました。必要なブランチ (例: 1.21.1) と、ブランチの開始リビジョンと終了リビジョン (例: 4 と 78 は、1.21.1.4 から 1.21.1.78 までのすべてのリビジョンを移行します) を指定します。すべてのブランチを 1 つのリポジトリに含めるには、インポートに使用する .git ディレクトリを指定します。

  • リビジョンの開始からリビジョンの終了までループを開始
    • CURRENTREV=BRANCH.loopcounter
    • レポディレクトリを作成する
    • .git ディレクトリを repo ディレクトリに移動します
    • .gitignore ファイルを repo ディレクトリに移動します
    • chdir を repo ディレクトリに
    • "si createsandbox -P MKS_PROJECT_PATH --yes --projectRevision=CURRENTREV を使用して、リポジトリ ディレクトリ内に mks サンドボックスを作成します。
    • 「si viewprojecthistory --rfilter=range:CURRENTREV-CURRENTREV」でリビジョンの説明を取得し、出力をキャプチャします。
    • 以前の出力からユーザー、日付、ラベル、コメントを抽出する
    • 「ギット追加。」
    • 上記から抽出された情報を「git commit -qF -」にパイプします（チェックポイントコメントのように複数行が必要な場合は、-m を実行できません）
    • 「sidropsandbox --yes index.pj」でサンドボックスを削除
    • .git と .gitignore を保存場所に移動します (次の反復のために)
    • サンドボックスディレクトリに残っているすべてのファイルを削除します
    • 親ディレクトリに移動 (..)
    • サンドボックス/レポディレクトリを削除
  • 最終的な git ディレクトリを作成する
  • .git と .gitignore を最終的な git ディレクトリに移動します
  • 「git reset --hard HEAD」

終わり。

MKS は文字列にある種の ASCII エンコーディングを使用し、git は通常 UTF-8 を使用するため、メタデータ (ユーザー名、コメント、タグなど) を git にインポートする際の問題に注意してください。

より多くのブランチについては、これを行います：

  • git ディレクトリで、ブランチを開始するリビジョンをチェックアウトし、ブランチを作成します ("git checkout -b NEWBRANCHNAME")
  • .git と .gitignore を保存場所に移動し、ディレクトリ全体を削除します
  • 今、上記と同じことをします

もう 1 つ、「si」は MKS コマンド ライン ツールです。したがって、その完全なパスを指定するか、そのパスを検索パスに入れる必要があります。

于 2011-03-12T12:43:06.853 に答える
8

MKS Integrityの問題は、すべてが存在する独自のリポジトリです。

  • 要件、
  • テスト計画、
  • テストケース、
  • 特徴、
  • 開発者のタスク
  • 導入リクエスト

これらのデータは、独自のペースで互いに独立して進化する可能性があるため、1 つの Git リポジトリにすべてをインポートすることはお勧めできません。Git リポジトリのすべてのコンテンツのクローンしか作成できません (そのクローンの深さを制限できる場合でも)。 ）。
つまり、コードに興味があるだけでも、すべてのドキュメントを取得できます。MKS Integrity エクスポートは、サブモジュール
として機能する最初の多くの Git リポジトリを定義することを意味します。

ソースツリーとその履歴だけが必要です。

いつものように、インポートのみをお勧めします。

  • メジャーレーベル（1年以上前のもの、またはあなたが快適だと感じる期間は、古いものなので完全に調べる必要はありません）
  • 過去数年間のすべてのラベル (メジャーおよびマイナー)。

そして、すべてのソースがすべてとして開発された1 つのシステムを表していると確信できない限り、 1 つのGit リポジトリにすべてをインポートすることはありません (独立して開発された複数の「モジュール」ではありません)。

より簡単な方法は、CP をチェックアウトして git に追加/コミットすることです。

それが進むべき道だろう。

しかし、そうすると、追加、削除、移動、および名前変更の操作を追跡できなくなります。

いいえ！あなたはしません！Git はこれらの操作を推測します。これが、ファイルContent VCS
であることの利点です。

于 2009-08-21T21:29:09.167 に答える
6

残念ながら、si diff は現在、統合 diff をサポートしていません。そうするために変更の要求がありますが、その機能を要求する顧客はまだあまり多くありません.

免責事項: 私は (MKS を買収した) PTC で働いています。

于 2012-07-09T19:34:49.610 に答える
3

これはチェックポイントで機能します...

https://gist.github.com/2369049

残念ながら、チェックポイントは、GIT がコミットと呼ぶ「スナップショット」に実際に最も近いものであるため、MKS -> GIT から実際に意味をなすのはチェックポイントだけのようです。

MKS には非常に多くの互換性のない概念 (ファイルごとのバージョン追跡、GIT ブランチとはまったく異なるブランチ、チェックポイントなど) があり、それらはすべて互いに独立して進化する可能性があるため、賢明な履歴を GIT に移行する方法を伝えるのは非常に困難です。おそらく多くの方法がありますが、次の方法よりも「正しい」方法はありません。

とは言っても、良いアイデアを聞きたいです。:)

ファイルごとのバージョン管理を適切な方法でキャプチャするソリューションが欲しいです。いくつかの議論の中で、MKS のファイルごとのバージョンをコミット時間などで並べようとするアイデアが飛び交いました。そうすれば、複数のファイルの変更を含むコミットを通じて進化する「レポ」の概念を定式化できます。

于 2012-04-15T03:45:41.127 に答える
0

このツールを使用して、変更パッケージを MKS から Mercurial にインポートします。git へのインポートは非​​常に似ているはずです。または、最初に Mercurial にインポートし、次に git ツールを使用して Mercurial をインポートすることもできます。

https://github.com/arsane/py-mks2hg.git

指定されたプロジェクトの下にあるすべての変更パッケージを見つけようとし、新しい Mercurial リポジトリに順番にコミットします。

于 2016-01-15T09:50:48.250 に答える