2012-02-13 1 views
1

を見つけた私は、バックアップから復旧し、驚くべきことに後にSVNリポジトリの問題を抱えていなければなりませんでした。 このリポジトリ上のすべての操作が失敗した、私がチェックアウトすることができない、輸出も回復しません。"svnadmin recover"の出力は次のとおりです。svnadmin:予想される現在のrevが51であることが判明しました52svnadminは:現在のrevは51であることが予想しかし52

作業コピーは安全ですが、このリポジトリを再び使用可能にするにはどうすればよいですか?

+0

できますが、 'のsvnadminのdump'導入されたときから文書comparing FS_FS to FS_Base that I foundに記載されていますか? –

+0

はい、最後のリビジョン以外のすべてをダンプします。私は助けてくれると思うよ、ありがとう! –

+0

バックアップはどうやってやるの?リビジョンが半分しかバックアップされていないという問題が発生する可能性がありますか? – vinnyjames

答えて

0

SVN documentation about the FS_FS backend.から読んでみたいですが、基本的に、あなたのレポの "db/current"というファイルは最新のリビジョン番号を持つテキストファイルですが、db/revs /はすべてのリビジョンのファイルを含むフォルダです(1.5以降はシャードフォルダ内で分割される可能性があります)。

あなたのバックアップツールがrevs /に退避してそこにあるすべてのファイルをバックアップし、バックアップ中にユーザーがコミットを行った場合、その最新のコミットを見落として、revファイルをdb /トランザクション/ db/revs /にはまだ増分されているdb /現在のファイルをバックアップします。それはあなたが最新のコミットとして51のリビジョンが、現在のリストの回転/「52」を持って、です!

バックアップの一貫性を保証するには、db /トランザクションを無視することが推奨されます(これはrevを構築する際に使用されるスクラッチスペースです)。バックアップdb/current前にdb/revsをバックアップしてください。ここでの最悪のケースは51に回転/含まれている可能性があり、例えば、52改定し、現在のポイントは、一貫性のある、すべてが正常に動作するということです。 "svnadmin recovery"はこれを修正します。

しかし、あなたがしなければないバックアップデシベル/現在の最初の(あなたはしなかったとして)それはvimの、ナノ、または別のテキストエディタで開き、単に数を増減することは非常に簡単です。あなたの場合、52を51に変更し、すべてが正しく検証されるはずです。

バックアップに関する部分もFS_FSが最初

関連する問題