web-dev-qa-db-ja.com

非常に大きなリモートSubversionリポジトリをスリム化されたGitリポジトリに変換する

2つの主要な要素で構成される14年前のSubversionリポジトリを引き継ぐことができて嬉しいです。

  1. 111,000の改訂。そのうちの約10％は大幅なものです。
  2. 長年にわたって更新、追加、変更された多数のバイナリデータファイルが原因で、リポジトリダンプは約73 GBです。

これが私がしたいことですが、それが可能かどうかはわかりません：バイナリファイルの履歴を取り除き、コードの変更のみを保持したいと思います。次に、それをgitに変換します。あなたのおすすめは何ですか？

gitsvnrepository
6
Ben

それが可能かどうかわからない：バイナリファイルの履歴を取り除き、コードの変更のみを保持したい。次に、それをgitに変換します。

私はこれを自分で試したわけではありませんが、上で説明した順序でタスクに正確にアプローチすると、これが可能であると確信しています。

  1. バイナリファイルの履歴を取り除き、コードの変更のみを保持しますSVNを最初に

  2. gitに移行後で。

ステップ1は、履歴を含むバイナリファイルを一時フォルダー（たとえば、svn moveを使用してリポジトリ内）に移動することで実行できます。次に、プロジェクトのローカル作業ディレクトリにそれらの新しいコピーを作成し、それらを新しいファイルであるかのようにチェックインします。そのため、これらの新しいファイルには履歴がありません。次に、この サーバー障害の質問 で説明されている手順を使用して、一時フォルダー（svnadmin dump、svndumpfilter、svnadmin loadを使用）を削除し、完全な歴史。

このように、プロジェクトの古いリビジョンをチェックアウトすると、バイナリファイルが完全に失われます。これが問題になるのを回避するには、@ RobertHarveyの提案に従って、古いSVNリポジトリをオンラインに保つ戦略を検討してください。

4
Doc Brown

OPはこちら。後世のために、私はこの問題に対する私の究極の解決策を追加したいと思いました。ベストアンサーはチェックされたままにします。これは、物事がスムーズに進むときに実際にベストアンサーになるためです。

まず、Doc Brownから選択した回答を試しました： https://softwareengineering.stackexchange.com/a/370419/291998

しかし、svnadmin dumpコマンドは、ダンプの約半分（ダンプの約1日）に失敗し、リビジョンが壊れていました。これは一貫した障害点でした。 svnadminダンプへのリビジョンフラグを注意深く使用することにより、この特定の参照をバイパスする試みは、完全なダンプを生成することができましたが、73 GBのダンプファイルからバイナリファイルをフィルターする試みは、さらに苛立ちを感じました。私はなんとか特定のブランチのダンプを作成することができましたが、これは完全な移行には役に立たなかった。

最終的に、私はgit-svnを使用してこれを行いました：Nohup git svn init https://myurl.com/projects/myproject/ --no-minimize-url --no-metadata --stdlayout &

このような大きなリポジトリでgit-svnを使用しても問題がありました。処理中に定期的に詰まる。さいわい、git svn fetchを発行して、各停止ポイントで変換を再開できます。失敗したときにそのコマンドを発行し続ける小さなラッパースクリプトを作成しました。

以上のことをすべて述べましたが、このタスクにはgit-svnを推奨しません。この記事を参照してください： http：//esr.ibiblio。 org /？p = 6778

しかし、これが最終的に私が作業できる唯一のツールでした。バイナリファイルを取り除くために、BFGレポクリーナーを使用しました https://rtyley.github.io/bfg-repo-cleaner/

4
Ben