2009-08-19 30 views
4

ここにどのようになっても、私はバックアップからSVNリポジトリを復元する立場にあります。残念ながら、バックアップはわずかに壊れており、19000件以上のリビジョンのうち約80件が失われています。バックアップはbzip2ファイルで、ブロックの約99%を回復するためにbzip2recoverを使用することができました。彼らは正常に圧縮解除されているので、これらは「良く知られています」。svnリカバリ - 個々のリビジョンを復元する

したがって、わかりやすいコミットのリストを作成でき、コミットが失われました。

元のリポジトリも破損していましたが、多くのファイルが存続しました。残念ながら、リポジトリ全体が壊れています。

私はこれらの不足しているリビジョンの元のdb/revsおよびdb/revpropsディレクトリのファイルを持つことができるほど幸運です。バックアップbz2ファイルの破損がdb/revsファイルの破損と揃っていない可能性があります。

私はr13892まですべてを再構築しましたが、r13893が壊れているので、r13893のダンプはありません。私は元のリポジトリからdb/revs/13893とdb/revprops/13893というファイルを持っています。

私はsvn-1.4でリポジトリを作成して再構築しましたが、svn-1.6にアップグレードしてselect svnadmin verifyコマンドを使用することができました。

おそらく私はこれらの2つのファイルを新しいリポジトリにドロップし、db/current [1]を更新してから続行することができると考えました。しかし、私はこのエラーを確認しようとするとき:

$ svnadmin verify new-svn 
* Verified revision 1. 
... 
* Verified revision 13889. 
* Verified revision 13890. 
* Verified revision 13891. 
* Verified revision 13892. 
svnadmin: Can't read file 'svn/db/revs/13214': End of file found 

これは明らかにうまくいきませんでした。 13214が何をしているのかはわかりません。

1.6で奇妙なことが起こった場合に備えて、私はsvn-1.4.6にダウングレードしました。残念ながら、私は同じ結果を得る - リビジョン13893が検証されていません。

... 
* Verified revision 13891. 
* Verified revision 13892. svnadmin: Can't read file 'svn/db/revs/13214': 
End of file found 

をだからここに私が知っているものだ:

  • 私は(13892の改訂1が100%正確であることを知っている限り、いくつかの非常に低い確率でbz2ブロックが正しく圧縮解除されていますが、チェックサムを渡しています)。
  • 元のSVNリポジトリからのr13893ファイルが正常であるかどうかわかりません - 破損している可能性がありますが、破損の量はそれほど少なかった(しかし可能です)。

私はこの穴をどのように埋めることができるでしょうか?私は所有しているr13894を100%自信が持っていることに注意してください。そうすれば、r13893プラグを差し込むことができれば、残りの復元と一緒に進むことができます。

[1]私はこのスクリプトでデシベル/電流を更新: http://svn.haxx.se/users/archive-2005-12/att-0630/make-current-fix.py

私は(/現在のDBへの書き込みを無効にした後!)他のいくつかのSVNリポジトリ上でこれ​​をテストし、それは同じ値を生成していることを確認するために、すでにそこにあるように。します。これについて

答えて

2

svnadmin: Can't read file 'svn/db/revs/13214': End of file found 

私はレブ13214から何かを参照することレブ13893(ファイルのコピーとして、またはスタッフ、または何か-REVのスキップ)疑い。

svnを読み込むときに、新しいリビジョンが元のリビジョンと一致しましたか?私のダンプがrev 0を参照し、rev 1としてロードされたケースを思い出しました。ここで何か起きている場合、rev 13214のバックリファレンスは1つだけオフになります。

repo dbのファイルを使用して、ダンプ形式で不足している回転を作成することがあります。残念ながら、私はそれを行うツールを知らない。しかし、私はSvnDumpToolを見ることをお勧めします。 svnダンプを多くの便利な方法で操作することができます。

開示:私は過去

+0

にsvndumptoolに貢献してきたはい、r13893の上部に、それは言う: DELTA 13214 0 12567271 は、だから、それは出番説明している、13214の上にデルタですから。私は気づく ことの一つは、(デシベル/回転域での)私の再構築されたバイナリのコミットはこれで始めるということです。 @<86>^@ SVN^A^@ ^しかし、私のオリジナルr13893は、このようなルックスをコミット: SVN^@^@<86>^@ "SVN"の後の最初のバイトは古いコミットの^ @(00)ですが、新しいコミットの^ A(01)です。これはxdeltaのバージョン番号ですか?おそらく、同じxdelta形式を使用するバージョンのSubversionで1から13892まで再構築する必要がありますか? – meowsqueak

+0

私は^ @ vs^Aについて知らない。しかし、ダンプをロードするときには、元のレヴァー番号が何であったか、新しく作成されたレビ番号が何であったかを教えてください。それらの2つの数字は一致しますか? – retracile

+1

はい、これらの数字は一致します。 私は実際にこの問題を解決しました。新しいリポジトリを1.4で作成したためでしたが、古いファイルは1.3で作成されたため、xdelta形式が異なりました。私はsvn-1.3でやり直したところ、この問題は解決されました。 残念ながら、svnadmin segfaultsは後で、すべてがあまりよくありません... – meowsqueak

関連する問題