ここにどのようになっても、私はバックアップから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リポジトリ上でこれをテストし、それは同じ値を生成していることを確認するために、すでにそこにあるように。します。これについて
にsvndumptoolに貢献してきたはい、r13893の上部に、それは言う: DELTA 13214 0 12567271 は、だから、それは出番説明している、13214の上にデルタですから。私は気づく ことの一つは、(デシベル/回転域での)私の再構築されたバイナリのコミットはこれで始めるということです。 @<86>^@ SVN^A^@ ^しかし、私のオリジナルr13893は、このようなルックスをコミット: SVN^@^@<86>^@ "SVN"の後の最初のバイトは古いコミットの^ @(00)ですが、新しいコミットの^ A(01)です。これはxdeltaのバージョン番号ですか?おそらく、同じxdelta形式を使用するバージョンのSubversionで1から13892まで再構築する必要がありますか? –
meowsqueak
私は^ @ vs^Aについて知らない。しかし、ダンプをロードするときには、元のレヴァー番号が何であったか、新しく作成されたレビ番号が何であったかを教えてください。それらの2つの数字は一致しますか? – retracile
はい、これらの数字は一致します。 私は実際にこの問題を解決しました。新しいリポジトリを1.4で作成したためでしたが、古いファイルは1.3で作成されたため、xdelta形式が異なりました。私はsvn-1.3でやり直したところ、この問題は解決されました。 残念ながら、svnadmin segfaultsは後で、すべてがあまりよくありません... – meowsqueak