あるサーバーから別のサーバーに転送する必要がある巨大なSVNリポジトリをインポートする必要があります。だから私はそれを古いサーバーからエクスポートしました：
svnadmin dump . > archive.svn
新しいものにインポートしました：
svnadmin load . < archive.svn
インポートプロセスの途中で、次のエラーが発生しました。
Cannot accept non-LF line endings in 'svn:ignore' property
どうすればこれを修正できますか？私は両方のサーバーを完全に制御できます。
ソースを修復するか、小道具の検証を無効にするという 2 つのオプションがあります。
ソースの修復(svn:log および svn:ignore) :
sed -e '/^svn:log$/,/^K / s/^M/ /' -e '/^svn:ignore$/,/^PROPS-END$/ s/^M/\n/' archive.svn > repaired-archive.svn
svnadmin load . < repaired-archive.svn
^ Mは制御文字で、16 進数で 0D を意味します。それを取得するには、 ^M (サーカムフレックス M またはコントロール M) の代わりに ^ V^M (コントロール V コントロール M ) を使用します。
小道具の検証を無効にする:
svnadmin load --bypass-prop-validation . < archive.svn
svnsyncちょっとした体操で、EOL を修正する機能を持つ を使用して、これを回避できます。リポジトリが にダンプされたとしましょうarchive.svn。
最初に、EOL の問題を無視して、レポジトリを再度ロードするためのレポジトリを作成します。
svnadmin create repo
svnadmin load repo < archive.svn --bypass-prop-validation
次に、コピー先の新しいリポジトリを作成します。
svnadmin create repo-fixed
svnsync使用しない場合でも、いくつかの pre-commit フックが必要なので、エディターを使用して に空のものを作成してくださいrepo-fixed/hooks/pre-revprop-change:
#!/bin/sh
exit 0
の宛先リポジトリを初期化しますsvnsync:
svnsync init file:///path/to/repo-fixed file:///path/to/repo
次に、リポジトリ全体をコピーします。
svnsync sync file:///path/to/repo-fixed
うわー！svnsync良いニュースさえあります: NOTE: Normalized svn:* properties to LF line endings(Subversion チームが同じ正規化を行うように更新しなかった理由はsvnadmin、私には謎です。)
それが完了したら、新しいリポジトリをダンプします。
svnadmin dump repo-fixed > archive-fixed.svn
これは、必要に応じて EOL が修正されていることを除いて、archive-fixed.svnと同じはずです。archive.svn
(オプション) に使用した一時リポジトリを削除できるようになりましたsvnsync。
rm -rf repo-fixed
更新この新しいダンプをロードすると、Subversion クライアントでエラーが発生することが判明しました:Repository UUID does not match expected UUID. を使用svnadmin setuuid ...して、UUID ID を以前のものに変更する必要があります。
(この投稿は、Web で見つけた多数のスニペットと部分的な解決策の集大成です。私よりも多くのことを知っていたすべての人々に感謝します。すべてをまとめただけです。)
以下も参照してください。
@ventura10の回答の最初のオプションは良さそうに聞こえましたが、うまくいきませんでした。このsedコマンドは、プロパティ セクション外のバージョン管理されたコンテンツを変更したため、ダンプの読み込み中に md5 の不一致が発生しました。
私のリポジトリにはバイナリ コンテンツを含むプロパティがないため、sed コマンドを変更して、 and だけでなくすべてのプロパティを修正しsvn:logましsvn:ignoreた。また、バージョン管理されたファイルに で始まる行が含まれていないことも確信していましたProp-content-length:。そうしないと、ダンプをロードするときにエラーが発生します。
sed -e '/^Prop-content-length: /,/^PROPS-END$/ s/^M/ /' svn.dump > svn.dump.repaired
プロパティ値のサイズを変更してはならないため、に置き換えることが重要^Mです 。[blank]
@ventura10 のメモはまだ有効です。
^M は制御文字で、16 進数で 0D を意味します。それを取得するには、^M (サーカムフレックス M またはコントロール M) の代わりに ^V^M (コントロール V コントロール M) を使用します。
既存のリポジトリを svn 1.4 から svn 1.7 にアップグレードすると、この手順が必要になるとは信じがたいですが、svn 1.6 以降受け入れられなくなったキャリッジ リターンを取り除く方法は他に見つかりませんでした。
サーバーのバージョンを変更しましたか? これは 1.6 の既知の問題であり、1.4 または 1.5 から移行すると問題が発生します。
Subversion 1.6 では、プロパティ ファイルでキャリッジ リターン (^M) を使用できなくなりました。svn:ignore ファイルの改行を修正するか、簡単であれば再作成する必要があります。
または、 Subversion 1.7を使用するか、uberSVNを使用することもできます。
svndumptoolを使用します:
svndumptool.py eolfix-prop svn:ignore svn.dump svn.dump.repaired
@tangens ソリューションも私にとってはうまくいきますが、キャリッジリターン文字の代わりに余分なスペース文字を取得しているため、完璧ではありません。ただし、svn:ignore がその余分なスペースで引き続き機能することをテストしましたが、他の SVN プロパティはテストしませんでした。
svndumptool を使用することの欠点は、一度に 1 つの svn プロパティしか操作できないことです。これは、ダンプ ファイルが大きい場合に時間がかかります。
いくつかの発見
@tangens が ^M を空の文字に置き換えなかった理由に興味があるかもしれません。空の文字に置き換えようとすると、次のエラーが発生します。
svnadmin: E140001: Dumpstream data appears to be malformed
ダンプ ファイルProp-content-lengthには、プロパティの実際の内容と照合されるプロパティが格納されます。^M を空の文字に置き換えると、プロパティ コンテンツの長さが短くなるため、エラーが発生します。
svndumptool はそれぞれ と を変更しProp-content-lengthますContent-length。
1.6 リポジトリを 1.8 にアップグレードするときに、このエラーが発生しました。ネット上で多くの「修正」を見つけました。
--bypass-prop-validationは、問題を延期するため、私には魅力的ではありませんでした。次にレポを復元する必要があるときに、同じ問題が発生します。
リビジョンをループしてコメントを取得して再度設定するbashスクリプトを見つけましたが、これは機能しませんでした。
ventura10 のソリューションの改善により、その仕事ができました。ダンプのサイズのため、ダンプの復元中に不要な文字を削除するために単一のコマンドを使用することになりました
sed -e '/^svn:log$/,/^K / s/^M/ /' -e '/^svn:ignore$/,/^PROPS-END$/ s/^M/\n/' /path/to/svn.dump | svnadmin load /path/to/repo
ノート：
^M は制御文字で、16 進数で 0D を意味します。それを取得するには、^M (サーカムフレックス M またはコントロール M) の代わりに ^V^M (コントロール V コントロール M) を使用します。