2

60以上のプロジェクトを含む大きくて巨大なずさんなSubversionリポジトリがあります。、、、trunkおよびディレクトリはリポジトリのルートにありますbranches。tagsいくつかのブランチが行われbranches/project/branchNameます。その他は行われbranches/BranchName/projectます。がらくたがたくさんあります。

ほぼ200,000のリビジョン、22Gb、および60以上のプロジェクトがあります。

リポジトリを再構築したいので、各プロジェクトには独自のリポジトリがあり、標準の分岐戦略を確立します。リポジトリ全体のダンプには約7〜8時間かかります。その後、svndumpfilter複数回実行する必要があるため、必要なものを除外するのは非常に長いプロセスです。

新しい戦略を考えています。1つのプロジェクトに関連するリビジョンを見ると、400のリビジョンについて話している可能性があります。svnadmin dumpさまざまなリビジョンで実行できることを知っています。興味のあるプロジェクトのリビジョンだけをダンプするとどうなりますか？svnadmin dumpリビジョンごとに実行できます。これは実際にはもっと速いかもしれないと思います。ただし、これは新しいリポジトリへのロードにどのように影響しますか？

必要なリビジョンだけを単にダンプするという問題はありますか？

4

1 に答える 1

1

私の頭に浮かぶ最初の問題は、新しいダンプを新しいリポジトリに直接ロードできないことです。これらのダンプには、親フォルダー (トランク/ブランチ/タグなど)を作成するためのノードがなく、svnadmin loadコマンドがエラーで失敗しFile not foundます。したがって、次のように事前に作成する必要があります。svn mkdir http://server/svn/ProjectX/Trunk -m "Created Trunk"

考え直してみると、プロジェクトへのコミットに相互参照がある場合、他のあらゆる種類の問題が発生する可能性があります。たとえば、 の 1000 から 1500 までのリビジョンをダンプし/branches/ProjectX/branchますが、ダンプ内の一部のノードにはヘッダーが含まれます。これは、開発者がそのプロジェクトの共有ファイルを必要としてコマンドを使用したためNode-copyfrom-rev: 800です。そして、ここでフィルタリングの狂気が始まります。それを軽減するために、svndumpfilterINスクリプトを使用してこれらのダンプを処理しようとする場合があります。これにより、ライブ リポジトリから不足しているファイルが. ただし、独自のバグがあることに注意してください (この質問に対する私の回答を参照してください: SVNDumpFilter を追加する前にパスを変更しますか? )。Node-copyfrom-path: /branches/ProjectY/branchsvn copysvnlook

3 番目の考えとして、プロジェクトごとに個別のリポジトリが必要な場合は、おそらく、ダンプされたプロジェクトをルート フォルダーに再配置することも必要になるでしょう。たとえば、Svn-DumpReloc、svndumpsanitizer (マージ ハックを使用したsvndumptoolについては不明) プロセスsvn:mergeinfoプロパティなど、ダンプ内のパスを再配置できる既知のツールはほとんどなく、ダンプのインポートが失敗します。

したがって、あなたの制約を考えると、後でリポジトリとダンプファイルを手動でいじる必要がない部分ダンプを使用した解決策はわかりません。

于 2015-02-09T16:46:25.380 に答える