問題タブ [version-control-migration]

枝分かれした mercurial リポジトリを git リポジトリに変換し、mercurialから git (一方向のみ) に変更をプルし続ける必要があります。既存の hg-to-git の回答は、ブランチを正しく処理していないようです。たとえば、'default' と 'br1' ブランチを持つ小さな hg リポジトリの結果は次のようになります。

Git は、ブランチ 'master' が 1 つしかないと考えています。 Mercurial ブランチを同じ名前の git ブランチとして表示するにはどうすればよいですか? 「デフォルト」の代わりに「マスター」を使用できますが、他のすべての名前付きブランチを git に含める必要があります。

複数の独立した git リポジトリに変えたい svn ツリーがあります。この移行の 1 つの側面は、Subversion ツリー内のクロスモジュール シンボリック リンクである inode を、git リポジトリ内の実際のファイル コンテンツに置き換える必要があることです。したがって、ある時点でA/fooが へのシンボリック リンクB/fooである場合、対応する git commit にA/fooは、 の内容を含む通常のファイルが必要ですB/foo。後で svn commit が のコンテンツを変更した場合B/foo、 の git モジュールにAは、この変更を反映する一致する commit が必要です。

これにはどのようなツールを使用できますか?

今のところ、これが私が思いつくことができる最高の計画です：

1. svn 全体を git にクローンします
2. fast-exportそれ
3. シンボリックリンクをコンテンツファイルに変換するために、カスタム作成のスローアウェイコードを使用して出力をマッサージします
4. fast-import結果を新しい単一の git リポジトリに
5. そこからサブモジュールを作成する

しかし、おそらく、既存のコード、既存の機能、既存のツール、または私が考えもしなかったショートカットを使用して、より簡単な解決策を提案できるでしょう。

おそらく、Subversion 側でこれらのステップをさらに処理する方法さえあるでしょう。私はファイルのサブバージョン コピーの作成を多用したため、また、その概念は git の概念ではほとんど表現できないことがわかっているため、上記のアプローチではコピーされたファイルが原因でバージョン履歴が失われるのではないかと心配しています。

C:\>git tf clone https://companyname.visualstudio.com/DefaultCollection $/companyname/Main OldTFS --deep

これはメインブランチの履歴のみを取得します。だったgit tf。

C:\>git tfs clone https://companyname.visualstudio.com/DefaultCollection $/companyname/Main --with-branches

マージ変更セットの 1 つでいくつかのブランチを取得した後、これは失敗しますPlease report this case to the git-tfs developpers! (report here : https://github.com/git-tfs/git-tfs/issues/461 )。git branchこれをくれる

Sprint085 までのブランチと、かなりの数のリリース ブランチもあります。あれはgit tfs

git tf履歴を適切に表示できるように、マージコミットを適切に作成する他のいくつかのブランチを取得できる方法はありますか?

クリア ケースで管理されているプロジェクトのバージョンを SVN に移行する予定です。そして、ポラリオンが提供する SVNImporter を試しました。小さな vob の移行には問題ありません。しかし、vob が大きい場合 (200mb)、ヒープのメモリ不足エラーが発生し ( -Xmx = 1024m を設定しました)、そのプロセスを実行するのが遅くなります。

CC から SVN への移行の経験があり、大きな clearcase vob で機能する他のオープン ソース ツールを知っている人はいますか? または、共有できる提案/ベストプラクティスは大歓迎です。

更新: クリア ケースのファイル、ブランチ、タグの履歴が必要です

最近、SVN から git に移行しました。残念ながら、トランクのみが移行されましたが、製品リビジョンのバグ修正用のブランチは移行されませんでした。8-{不足しているブランチを数か月後に移行することは可能ですか? 残念ながら、リポジトリの作業をしばらく行っているため、完全な移行を再度行うのは面倒です。

バックグラウンド

CVS リポジトリからコードを回収しようとしています。私はreposurgeon目的のために使用しており、git-fast-importストリームを取得するために次のツールを試しました。

• cvs-fast-export、エラーになります（循環分岐とされていますが、詳細は提供されていません）
• cvs2gitが続きgit-fast-export、理解を超えて物事をマッシュアップします
• git-cvsimportこれはgit-fast-export、これまでのところ最高の結果を生み出しますが、属していないブランチに何かを投げることになります。

この CVS リポジトリはさまざまな CVS バージョンで実行されており、タグとブランチは強制的に移動されています。これは、それらのブランチとタグをもうサルベージできないことを意味することを知っています。しかし、それはそうです。

それにもかかわらず、私は（さらに多くの中から）半ダースのブランチを持っており、ストリームMAINへの変換中に保持することに興味がありgit-fast-importます。ターゲットの VCS はGit ではありませんreposurgeonが、ポイントは入力をこのように処理し、出力もこのように処理することです。

アーティファクトを理解し、古いもの (孤立したリビジョンを含む) を前処理段階でrcs -o<rev>(もちろん、私のレポのコピーで;)) きれいにするためには、どのようにrcsfileフォーマット作業の内部。

rcsfile.pyからモジュールを変更した後の解析は簡単ですrcsgrep。しかし、リビジョン番号、特に対応するデルタ+ログがないリビジョン番号が何を意味するかについての情報はまだ提供されていません。

私が見るもの

RCS ファイルのマニュアル ページによると、リビジョン ID の 3 番目のセグメントが 0 であってはなりません。

これが私がやったことです（実験として）。

1. On MAIN: ファイルをコミットします ( 1.1)
2. From MAIN: 分岐先BranchX( 1.1)
3. オンBranchX: ファイルを変更します ( 1.1.2.1)
4. オンBranchX: ファイルを再度変更します ( 1.1.2.2)
5. オンMAIN: ファイルを変更します ( 1.2)
6. オンMAIN: ファイルにタグを付けるfoobar( 1.2)
7. From MAIN: branch to BranchX、branch タグ ( ) を移動1.2し、前のブランチを事実上孤立させます。1.1.2.x
8. On BranchX: ファイルを削除 ( 1.2.2.1)
9. オンMAIN: ファイルを変更します ( 1.3)
10. オンMAIN: ファイルに強制的にタグを付けるfoobar( 1.3)
11. オンMAIN: ファイルを変更します ( 1.4)
12. オンMAIN: ファイルにタグを付けるfoobarbaz( 1.4)

上記のリストと以下の完全に再現されたファイルでわかるように、1.2.0.2ログ付きデルタの形でのリビジョンはありません。

今私の質問

リビジョンを新たに分岐するとx.y(ファイルの変更はありません!)、結果のリビジョン ID はx.y.0.2. これは、私が見て質問している謎のリビジョン ID に似ています。

• 0ファイルにデルタがないことを示しているので、実際の内容については祖先に戻る必要がありますか?
• それとも、0 は単にそのブランチの「ルート」を示し、4 番目のセグメントがそのブランチの最新リビジョンであることを示していますか?

誰かがこれらの質問に光を当てたり、上記のリンクされたマニュアルページよりも包括的な資料を指摘したりできますか?

以下は、完全な RCS ファイルです。

svn から git に移行しようとしています。以下のツールを使ってやってみました

ただし、両方のツールは、.gitファイルとフォルダーをチェックアウトせずに、フォルダーのみを作成しました (作業コピーを話します)。

git-svn私は以下を実行しようとしました

私は正確に何を間違っていますか？

ps グーグルを試してみましたが、すべてのブログで、これらのコマンドの両方がすべてのファイルとフォルダーを含むローカル リポジトリを作成する必要があると主張しています。また、hg convert を使用して svn プロジェクトを mercurial プロジェクトに変換したこともあります。svn プロジェクトを mercurial プロジェクトに変換した後、hg up などを実行して、プロジェクトのすべてのファイルとフォルダーを取得し、そのプロジェクトを mercurial サーバーに簡単にプッシュできました。ここにあるのは .git フォルダーだけです。どのステップが欠落しているか、正確に何が間違っていますか?

Mercurial では、まだプッシュする準備ができていない作業を追跡するために、秘密のチェンジセットを定期的に使用しています。次に、一部のファイルに緊急の変更を加える必要がある場合は、公開リビジョンに更新し、その変更を行ってプッシュすることができます。未完成の変更セットがプッシュされることを心配する必要はありません。

いいえ:

gitでこれをどのように行いますか?