先日、svnサーバにてリポジトリデータがなくなりデータ復旧ができない現象が発生しました。
その後、別のPCにてsvnサーバを設置し、別のHDDにてバックアップしておいたリポジトリデータをこのsvnサーバに設置しました。
tortoise svnのRelocate..機能で新サーバのipアドレスに切り替えて、フォルダ内のアップデートができるようになりました。
ただ必ず”No such revision 1437”というエラーを出力するようになりました。
showlogで履歴を確認すると、このバックアップのリポジトリは最終のrevisionは1428で昨年の12月ごろと確認できました。
最近のコミットは1か月くらい前だと思うので、それが1437だと思うのですが、この抜けたrevisionのエラーはどのように回避すればよいかご教示頂きますようよろしくお願い致します。
(追記)
自分のPCのsvnで管理しているフォルダをRelocate..機能で新しいsvnサーバのipに切り替えてのupdateでエラーが出る現象(No such revision 1437”というエラー)は回避できていないのですが、
新しいsvnサーバから、直接checkoutを実施した場合は、特にエラーが出ないことがわかりました。
この場合、Relocate機能での新規コミットで、コミットできていないファイルの追加というのは難しいということでしょうか?
やはり、checkoutしてエラーが出ていないフォルダに、コミットできていないファイルを追加してコミットするのが無難でしょうか?
(7/28 再追記)
Relocate機能(再配置機能)について調べていて、
https://tortoisesvn.net/docs/nightly/TortoiseSVN_ja/tsvn-dug-relocate.html
こちらのサイトを読んでいて、次のような文を見つけました。
再配置を使用すると、作業コピーを破損してしまい、更新、コミット、etc. でわけの分からないエラーメッセージを見ることになります。こうなってしまったら、新しくチェックアウトするしかありません。
やはり、1428までしかないリポジトリに対して、1429~1437のリビジョンの変更がある作業フォルダを再配置してエラーが発生した場合は、
リポジトリからrev1428までをcheckoutして、rev1437までの変更の入っている作業フォルダの差分のファイルをcheckoutした作業フォルダに入れて、rev1429としてコミットという作業が一番良い方法でしょうか?
どうぞ、ご教授よろしくお願いします。
あなたの回答
tips
プレビュー