5 年前から借りている専用サーバーのマザーボードが故障したため、新しいものに交換しました。非常に古い (Debian) ディストリビューションでは、マザーボード上のすべての新しいハードウェアに対応できなかったため、新しいディストリビューション (Debian Wheezy) を最初から再インストールすることにしました (アップグレードを行うことも、古い Debian では新しいマザーボードのイーサネット チップセットを認識しない可能性があるため、問題があったため、最初から再インストールすることにしました)。
SVN を再インストールし、以下の操作を実行してすべてのリポジトリを取得しました。
tar -xzf repoBackups.tgz
そしてそれは「機能」します。
問題は、たとえば Eclipse が SVN リポジトリを認識しているにもかかわらず、それらが同一であるにもかかわらず、すべてのファイルをコミットしようとすることです。
これはファイルのタイムスタンプに関係しているのでしょうか? いずれにしても、この問題の原因と解決方法について何かお考えはありますか?
私できた単純に、すべてのプロジェクトのすべてのファイルを再コミットするように全員に依頼すれば、すべて問題ないと思いますが、これらのプロジェクトの一部は非常に大きく、開発者にとっては少々面倒です。
ボーナス(それほど重要ではない)の質問:Git や Mercurial などの別の VCS はこの問題に「悩まされない」のでしょうか?
答え1
Subversionリポジトリのファイルをコピーすることは、サポートされているバックアップ方法ではありません。([SVN]: リポジトリをバックアップするにはどうすればいいですか?そしてSubversion リポジトリをバックアップする最良の方法は何ですか?そしてリモートSVNリポジトリをバックアップするにはどうすればいいですか適切な方法については、こちらを参照してください。データベースが破損した状態になっているようです。
svnadmin dump
解凍されたリポジトリと結果のダンプで実行してみてくださいsvnadmin load
。これにより、動作するリポジトリが得られる可能性があります (ただし、保証はできません。私は svn にあまり詳しくありません)。
ファイルのタイムスタンプは無関係です。Subversion はコミットするかどうかを決定するためにタイムスタンプを使用せず、リビジョン番号を使用します。