MKS Integrity リポジトリを git にインポートすることはできますか?

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

質問

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

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

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

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

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

何か案は？

編集2:
実際に移行をどのように行ったかを示す回答を追加しました...

役に立ちましたか？

解決

問題点 MKS インテグリティ 独自のリポジトリです。 すべて 住んでいます:

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

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

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

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

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

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

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

それが今後の進め方でしょう。

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

いいえ！そうは思わないでしょう！Git は 推測する それらの操作.
それがファイルであることの利点です コンテンツ VCS.

他のヒント

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

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

終わり。

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

さらにブランチを追加するには、次のようにします。

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

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

FWIW、SIのdiffは悲しげに、現在unified diff形式をサポートしていません。それはそう持っている変更の要求がありますが、まだその機能を求めるあまりにも多くの顧客が存在していなかった。

免責事項：私は（MKSを買収）PTCのために働く。

このチェックポイントのために働く...

https://gist.github.com/2369049する

チェックポイントは本当にGITコミット呼び出しを「スナップショット」に近いものであるとして、> GIT -

残念ながら、チェックポイントは、一見、本当にMKSから任意の理にかなっている唯一のものです。

MKSは、（ファイルバージョンの追跡あたり、GITブランチ、チェックポイントなどのような何もない支店）非常に多くの互換性のない概念GITに賢明な歴史を移行する方法を伝えるために、すべてが互いにそれは本当に難しいですから独立して進化させることができています。次のより多くの「正しい」おそらく多くのことを行う方法と、それらのどれもがあります。

私はいくつかの良いアイデアを聞いてみたい、と述べました。 ：）

私は賢明な方法でファイルごとのバージョン管理をキャプチャソリューションを見てみたいです。いくつかの議論では、我々は、コミット時か何かでMKS単位のファイルのバージョンをラインアップしようとしているのアイデアを中心に投げてきました。そうすれば、私たちは、複数のファイルの変更を含むコミットを通じて進化する「レポ」の概念を定式化することができます。

私は、MercurialのにMKSから変更パッケージをインポートし、非常に類似しているはずのgitにインポートするために、このツールを使用します。またはあなたが最初に水銀、およびMercurialの次をインポートするGitのツールを使用してインポートすることができます。

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

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

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