最初のgit-svnフェッチを高速化
私は大きなリポジトリを持っており、非常に高い分岐係数を持つ100,000以上のリビジョンがあります。 git-svnを使用した完全なSVNリポジトリの最初のフェッチは、約2か月間実行されており、リビジョン60,000までしかありません。このことをスピードアップする方法はありますか？
Git-svnがふるいのようにメモリをリークしているため、私はすでに定期的にフェッチを強制終了して再起動しています。転送はローカルLANを介して行われるため、リンク速度は問題になりません。リポジトリは、専用のファイバチャネルアレイに支えられた専用のマシン上にあるため、サーバーには十分な機能が必要です。私が考えることができる他の唯一のことは、SVNリポジトリのローカルコピーからクローンを作成することです。
同様の状況で他の人は何をしましたか？
どうやら良い答えはありません。 git-fast-importでいくつかの作業が行われていますが、まだプライムタイムの準備ができていません。彼らはまだ「svncp」アクションを検出して表現する方法を理解しようとしています。 1つの明るい点は、リストの誰かがgit-svnの最適化を思いついたことです。これは大きな影響を与えたようです。
http://permalink.gmane.org/gmane.comp.version-control.git/168718
仕事では、〜170000リビジョンのSVNリポジトリに対してgit-svnを使用します。私がしたことは、git-svn init + git-svn fetch -r...を使用して、最初のフェッチを妥当な数のリビジョンに制限することでした。実際に必要なブランチにあるリビジョンを選択するように注意する必要があります。切り捨てられた履歴exceptgit-blameでも、すべてが完全に機能します。これは、開始回転より古いすべての行を最初の回転に明らかに帰属させます。
不要なサブツリーを削除するためのignore-pathを使用して、これをさらに高速化できます。
後でリビジョンを追加することはできますが、面倒です。リビジョンマップをリセットする必要があります（残念ながら私はgit-svn resetと書いたのですが、すべてのリビジョンが削除されるかどうかはわかりません。 、それは手作業かもしれません）。次に、git-svn fetchのリビジョンと、git-filter-branchを使用して、古いルートを新しいツリーに再ペアレント化します。これにより、すべてのコミットが書き換えられますが、ソースBLOB自体には影響しません。人々がsvnリポジトリの大規模な再編成を行う場合は、同様の手術を行う必要があります。
実際にallのリビジョンが必要な場合（たとえば、移行の場合）、svn-fast-export + git-fast-importのフレーバーを確認する必要があります。 git-svnに一致するようにrevタグを追加するものがあるかもしれません。その場合、高速インポートして、svnリモートに移植することができます。既存のsvn-fast-exportオプションにその機能がない場合でも、元のクローンが完了する前に追加できる可能性があります。
20kのコミットがあるリポジトリでは、同様の問題が発生しました。私の場合、Subversionに問題を引き起こす奇妙なタグがいくつかあることがわかりました。/trunkの代わりに/をコピーしたタグがありました。これにより、git svnfetchが無限ループに入ります。チャンクに変換して修正しました。
git svn fetch -r0:1000
git svn fetch -r0:2000
git svn fetch -r0:3000
出力を見て、新しいrが表示されない場合は、ときどき問題が発生しています。使用する git log --allコンバージョンがどこまで進んだかを確認します。 1565に到達したとしましょう。次に、このようにフェッチを続行します。
git svn fetch -r1567:2000
それは非常に退屈でしたが、それは仕事を成し遂げました。
十分なRAMを備えたサーバーが見つかった場合は、RAMディスクでクローン操作全体を実行します。 Linuxシステムでは、RAMに支えられた/ dev/shmを使用できます。
> svnadmin hotcopy /path/to/svn/repo /dev/shm/svn-repo
> git svn clone file:///dev/shm/svn-repo /dev/shm/git-repo
それが完了したら、ここで説明するように、代わりにgitリポジトリを実際のsvnリポジトリに戻すことができます： https://git.wiki.kernel.org/index.php/GitSvnSwitch
- .git/configのsvn-remoteurl URLを編集して、新しいドメイン名を指すようにします
- Git svn fetchを実行します-これは、svnから少なくとも1つの新しいリビジョンをフェッチする必要があります！
- Svn-remoteurlを元のURLに戻します
- Git svn rebase -lを実行して、ローカルリベースを実行します（最後のフェッチ操作で行われた変更を使用）
- Svn-remoteurlを新しいURLに戻します
- Git svn rebaseを実行すると、再び機能するはずです！
これは、git svnfetchステップが実際に何かをフェッチする場合にのみ機能します。 （それを発見するのにしばらく時間がかかりました...それを実現するには、svnリポジトリにダミーのリビジョンを追加する必要がありました！）
私はこれを行ったところ、約3時間で4.7G12000リビジョンのsvnリポジトリをgitに複製することができました。
私は8000以上のレビューと約240のタグを持つレポを持っています。私は実行しようとしましたが、Windowsでの最初のgitsvnクローンは数か月かかると推定しました。
git svn clone --stdlayout --no-metadata --authors-file=users.txt https://link.to.repo
クローンは、平均して1つのリビジョンをインポートするのに5秒かかっていました。タグが検出されるたびに、クローンはリビジョン1から再起動するため、8k * 240操作= 111日になる可能性があることに注意してください。
プロセスをスピードアップするために私が取ったすべてのステップの要約：
linuxとosxの実装は、Windowsでのcygwinよりもはるかに高速です。 Linux仮想マシンを使用しました。確認してください https://stackoverflow.com/a/21599759/1448276
Svnrdumpを使用してsvnリポジトリ全体を自分のマシンにコピーしました
svnrdump dump https://link.to.repo > repos.dump
ローカルのsvnリポジトリを作成しました
svnadmin create svnreposvnadmin load svnrepo < repos.dump
https://stackoverflow.com/a/10407464/1448276 のように
RAMベースのディスクを作成してマウントしました
svnadmin hotcopy svnrepo/ /dev/shm/svnrepo
上記のように、 https://stackoverflow.com/a/39030862/1448276
そして最後にクローンを実行しました
git svn clone --stdlayout --no-metadata --prefix=Origin/ --authors-file=users.txt file:///dev/shm/svnrepo
ここでは、クローンは1秒あたり平均12.5のリビジョンを処理しているので、2日もかからないと思います。クローンが完成したら、更新を投稿します。
私はあなたが正しい軌道に乗っていると思います
ローカルファイルアクセスにより、1〜2注文のスピードアップが可能になります。
Bdbまたはファイルベースのsvnバックエンドに対してgitsvnを実行する方が速いかどうかはわかりません。
以前、git-svnを使用して100,000に近いリビジョンのSVNリポジトリをダウンロードしました。約48時間かかり、ローカルLAN経由でnotでした。確かに、あなたはあなたのリポジトリが高い分岐係数を持っていると言いましたが、私がダウンロードしたリポジトリはそうではありませんでした（それは数十の分岐を持っていましたが）
ボトルネックがどこにあるのかを理解することに取り組むことをお勧めします。 git-svnとそのサブプロセスは100％CPUを使用していますか？クライアントまたはSVNサーバーのディスクライトが常に点灯していますか？どのくらいの帯域幅が使用されていますか？制限要因が何であるかを知ったら、それを修正する方法を理解することに取り組むことができます。
2017年に電話がありました。45kリビジョンリポジトリを移行していますが、Linuxのgit-svnがWindowsボックスのgit-svnよりも約10倍高速に動作していることがわかりました。 Vm is私のsvnリポジトリと同じHyperVにあるので、それである可能性があります。