大規模なSubversionリポジトリから独自のリポジトリにディレクトリを分割し、そのディレクトリ内のファイルの履歴を保持したいと考えています。
最初に通常の方法で試しました
svnadmin dump /path/to/repo > largerepo.dump
cat largerepo.dump | svndumpfilter include my/directory >mydir.dump
しかし、それは機能しません。何年にもわたってディレクトリが移動およびコピーされ、ファイルがリポジトリ内およびリポジトリ外の他の部分に移動されたためです。結果はこれらの多くです:
svndumpfilter: Invalid copy source path '/some/old/path'
次に試したのは、それらを含めることです/some/old/path
それらが表示され、含まれるファイルとディレクトリの長い長いリストの後、svndumpfilterは完了しますが、結果のダンプをインポートしても、現在のディレクトリと同じファイルが生成されません。
では、履歴を保持しながら、そのリポジトリからディレクトリを適切に分割するにはどうすればよいですか?
EDIT:私は特に欲しいtrunk/myproj
新しいリポジトリのトランクになるPLUS新しいリポジトリには、他の古いものを一切含めないようにしてください。分割する前に誰かが古いリビジョンに更新してファイルを取得/参照する可能性があってはなりません。
私が試したsvndumpfilterソリューションは正確にそれを達成しますが、残念ながら、パス/ファイルが移動されたため、実行できません。 ngによるソリューション は、基本的に、関連するmyproj履歴だけでなく、すべての履歴を保持するエクストラのクローン+削除であるため、アクセスできません。
この問題は、svndumpfilterによって含まれるディレクトリ/ファイルの1つが、含まれていないツリーのセクションからコピーまたは移動されたときに発生します。
この問題を解決するには、次のスクリプトを使用します。 svndumpfilter
リポジトリの分割で同様の問題が発生しました。
svndumpfilter: Invalid copy source path /dir/old_dir
問題を回避するために私がしたことは、要求していた、またはあなたが移動したことを知っている追加の古いディレクトリを含めることでした。私の場合、3つのディレクトリを別のディレクトリに移動しました。
例えば。フォルダーA、B、CをフォルダーDに移動
cat project.dump | svndumpfilter include A B C D > new.dump
これで私の問題は解決したようです。フォルダDを残りのレポから分離することができました。反対に、Dを除外するとエラーが発生しなかったのではないかと思います。Dを削除するのにA、B、Cへのリンク/履歴は必要なかったからです。
私はそれを行うために少なくとも4つの異なるアプリケーションを試しましたが、が実際に機能したのは svndumpfilterINを使用することだけでした:
cd /usr/local/bin/
Sudo wget --no-check-certificate https://raw.github.com/jasperlee108/svndumpfilterIN/master/svndumpfilter.py
Sudo chmod +x svndumpfilter.py
# To be sure nothing will happened on the original repo :
cp -au /path/to/repo /tmp/largerepo.repo/
svnadmin dump /path/to/repo > /tmp/largerepo.dump
svndumpfilter.py /tmp/largerepo.dump --repo=/tmp/largerepo.repo --output-dump=/tmp/mydir.dump include my/directory
これが私が試したものであり、うまくいきませんでした:
auriarteのsvndumpfilter3 404へのリンク。これは、それを探している人のための(2011-01-31現在の)作業リンクです: http://furius.ca/pubcode/pub/conf/bin/svndumpfilter3.html
これはあなたに役立つ可能性があります: http://svnbook.red-bean.com/en/1.5/svn.reposadmin.maint.html#svn.reposadmin.maint.replication からの引用
Subversion 1.5では、svnsyncにより、リポジトリ全体ではなく、リポジトリのサブセットもミラーリングできるようになりました。このようなミラーのセットアップと維持のプロセスは、リポジトリ全体をミラーリングする場合とまったく同じですが、svnsync initを実行するときにソースリポジトリのルートURLを指定する代わりに、そのリポジトリ内のサブディレクトリのURLを指定します。そのミラーへの同期は、そのソースリポジトリサブディレクトリの下で変更されたビットのみをコピーします。ただし、このサポートにはいくつかの制限があります。まず、ソースリポジトリの複数の独立したサブディレクトリを単一のミラーリポジトリにミラーリングすることはできません。代わりに、両方に共通の親ディレクトリをミラーリングする必要があります。次に、フィルタリングロジックは完全にパスベースであるため、ミラーリングしているサブディレクトリの名前が以前に変更された場合、指定したURLにディレクトリが表示されるため、ミラーにはリビジョンのみが含まれます。同様に、将来、ソースサブディレクトリの名前が変更された場合、指定したソースURLが無効になった時点で、同期プロセスはデータのミラーリングを停止します。
もちろん問題は、名前変更前の履歴が失われることです...
プロジェクトを(Google Codeの)既存の統合リポジトリから独自のリポジトリに正常に移行しました。ここの投稿はとても役に立ちました。
これが最終的に私のために働いたものです...
svnadmin dump to foo-dumpfile
cat dumpfile | ./svndumpfilter3 --untangle mymirrorrepo trunk/foo > foo-dumpfile
svnadmin create foorepo
svnadmin load foorepo --ignore-uuid < foo-dumpfile
手順3の--untangle
オプションは、svndumpfilterとsvndumpfilter2を妨げるすべてのパスの問題を解決しました。
最初は、ステップ5でエラーが発生しました。
<<< Started new transaction, based on original revision 2
svnadmin: File not found: transaction '1-1', path 'trunk/foo'
しかし、Charles Calvertのブログのこの post は、ロードを実行する前にfoorepoにトランクディレクトリを作成することだけが必要であることを説明しました。
この問題が発生し、svndumpfilter2を使用してしまいました。
具体的には、このコマンド:
Sudo svnadmin dump /home/setup/svn/repos/main_repl | Sudo ./svndumpfilter2.py /home/setup/svn/repos/main_repl Development QA compliance > ~/main_repl_dump.trim
前述のメモリ不足エラーは発生しましたが、svnをVMで実行していたため、メモリを最大2Gに増やしました。これは誰にとっても選択肢ではないかもしれないと私は理解していますが、512Mの場合よりもはるか高速に実行されていることに気付きました。 (2Gはおそらく必要ありませんでした)。
現在、リビジョン18,631を処理しています。
誰かが不思議に思うかもしれませんが、私がリポジトリの一部を分割する必要があったのは、リポジトリの別のパスにあるファイルの実装に配布するためのタグ/コピーを作成していたからです。何らかの理由で、このプロセスにより、リポジトリは巨大な比率に膨らみました。 (現在は17Gです。)
Debian Lenny 5.0.4のSVNバージョン1.5.6のレプリケーションリポジトリでこれを行っています。
この問題に遭遇し、このツールを見つけました svndumpsanitizer 作成したファイルを新しいリポジトリにインポートできたようです。
リポジトリ全体を複製せずに、新しいリポジトリにダンプします。次に、幹を分岐し、頭を削除して、分岐から幹に戻す部分をマージします。次に、履歴を保持し、必要な部分を新しいリポジトリに分割しました。
このようにして、すべての履歴を保持し、必要な部分を選択して選択しました。
私もこの質問に対する答えを探しています(自分で対処する必要があります)。アレックスの答えに基づいて、私は http://furius.ca/pubcode/pub/conf/common/bin/svndumpfilter3.html を見つけました。これは、svndumpfilter2の問題のいくつかを修正すると主張しています。それは部分的な解決策だと思います。
良い:
純粋なPythonでのSubversionのsvndumpfilterの書き直し。これにより、除外されたファイルとディレクトリのセットの間の移動/コピー操作を追加に変換することにより、それらのもつれを解くことができます。このオプションを使用すると、指定されたリポジトリーから元のファイルがフェッチされます。
懸念:
重要
このスクリプトのバグを報告している人もいます。これは、大規模なリポジトリに空のファイルを作成するというものです。私のリポジトリで行わなければならなかった分割にはうまくいきましたが、他の人のリポジトリで発生する問題を修正する時間はありません
特定のコマンドは次のとおりです。リポジトリがhttp(s)://サーバーでホストされていると想定しますが、svn://またはfile://でも同じコマンドが機能します。
svnadmin dump /path/to/repository > dumpfile
svnadmin create /path/to/new_repository
svnadmin load /path/to/new_repository < dumpfile
svn co https://localhost/svn/new_repository_url new_repository_checkout
cd new_repository_checkout
svn move https://localhost/svn/new_repository_url/trunk https://localhost/svn/new_repository_url/branches/head -m "Moving HEAD to branches"
svn move https://localhost/svn/new_repository_url/branches/head/whatever https://localhost/svn/new_repository_url/trunk -m "Creating new trunk"
svn update
cd branches
svn remove head
svn commit
これで、古いリポジトリから必要な部分を新しいもののトランクとして使用できます。
この問題に遭遇し、無効なソースパスがすべて解決されるまでダンプを再試行する小さなスクリプトを作成しました。
#!/usr/bin/env Ruby
require 'open3'
include Open3
paths = [ "/your/path" ]
command = ""
new_path = "xx"
while (! new_path.nil?)
lines = nil
popen3(" svndumpfilter include #{paths.join(' ')} > svn.result.dump < svn.original.dump") do |i, o, err|
i.close
puts "Processing, please wait ..."
lines = err.readlines
end
new_path = nil
lines.each do |line|
if line =~ /Invalid copy source path '(.*)'/
new_path = $1
end
end
puts "Adding #{new_path}"
paths << new_path
end
Ng。による回答に基づいていますが、空のリビジョンをフィルタリングして削除します。
ステップ1。ダンプとフィルター:
svnadmin dump /path/to/repository > fulldumpfile
svndumpfilter include trunk/the/part/you/want --drop-empty-revs --renumber-revs < fulldumpfile > dumpfile
ステップ2。新しいリポジトリを作成します。 (これは、たとえばTortoise SVNでも実行できることに注意してください)
svnadmin create /path/to/new_repo
チェックアウトできるようにするために必要なもの(権限など)を忘れずに追加してください。
ステップ3。チェックアウトしてベースフォルダーを追加(Tortoise SVNなどでも実行できます)
svn checkout http://localhost/new_repo /some/checkout/path/newrepo
cd /some/checkout/path/newrepo
# to be able to create "trunk/the/part/you/want" you will need to add parent dir:
mkdir -p trunk/the/part/you
svn add trunk
svn commit -m "old base"
ステップ4。フィルターされたダンプをロード
svnadmin load /path/to/new_repo < dumpfile
ステップ5。古いルートを新しいルートに移動します(Tortoise SVNなどでも実行できます)
cd /some/checkout/path/newrepo
svn update
svn move trunk/the/part/you/want/* trunk/
svn move tags/the/part/you/want/* tags/
svn move branches/the/part/you/want/* branches/
svn commit -m "re-structure base"
これで、古いリポジトリから必要な部分を新しいもののトランクとして使用できます。
履歴全体が必要ない場合は、エラーの直後から取得できます。エラーがリビジョン412にあった場合は、次のようにしてすぐにエラーをピックアップできます。
svnadmin dump /path/to/repo -r 413:HEAD > largerepo.dump
これも完璧な解決策ではないかもしれませんが、あなたの場合はそれで十分かもしれません。
また、これをすべて1つのステップで実行することもできます。
svnadmin dump /path/to/repo -r 413:HEAD | svndumpfilter include my/directory > mydir.dump
Svndumpfilterと修正方法の詳細- http://blog.rlucas.net/uncategorized/some-gotchas-with-using-svndumpfilter/
または、現在はsvndumpfilter2と呼ばれているsvndumpfilter置換スクリプトを試すこともできます- http://cogo.wordpress.com/2009/03/10/problems-with-svndumpfilter/
私はそのスクリプトを試していませんでした。テストするために、レポバックアップを作成するのに少し時間が必要です(Windowsで使用できるバックアップダンプがあり、これはLinuxスクリプトです)。
私たちは Subdivision を開発しました。これは、svnリポジトリを分割するために設計されたGUIツールです。
サブディビジョンはリポジトリを分析し、ファイルがリポジトリ全体にコピーおよび移動されるときにファイルの履歴を計算します。この情報を使用して、すべての「無効なコピー元パス」エラーを回避するために、選択がインテリジェントに拡張されます。
リポジトリの分割に加えて、Subdivisionを使用すると、リポジトリからファイルを削除したり、ファイルやフォルダを新しいリポジトリに抽出したりできます。
小さなリポジトリの場合、サブディビジョンは無料です。