Subversion クライアントが何らかの方法でリポジトリを破壊することは可能ですか? これはあらゆる種類の破壊的な中断である可能性がありますが、バックアップからリポジトリを復元しない限り回復できないようなものでなければなりません。
明らかに、すべてを削除してから、ロールバックだけで簡単に修正できることを確認しているので、それ以上のものを探しています。
Subversion クライアントが何らかの方法でリポジトリを破壊することは可能ですか? これはあらゆる種類の破壊的な中断である可能性がありますが、バックアップからリポジトリを復元しない限り回復できないようなものでなければなりません。
明らかに、すべてを削除してから、ロールバックだけで簡単に修正できることを確認しているので、それ以上のものを探しています。
Subversion クライアントは、サーバーと通信してリポジトリにアクセスするか、file://
URL を使用してリポジトリに直接アクセスできます。最初のケースでは、サーバーがリポジトリを担当するため、クライアントはリポジトリを直接「壊す」ことができません。2 番目のケースでは、クライアントがリポジトリを担当するため、クライアントのバグがリポジトリに影響を与える可能性があります。
理論的には、Subversion はアトミック コミットを使用するため、リポジトリが破損することはありません (Subversion のバグにもかかわらず)。
ただし、アクセス制御を無視すると、クライアントはもちろん、新しいリビジョンでリポジトリのコンテンツを移動/コピー/削除できます。古いリビジョンが引き続き存在します。理論的には、svn コマンドを適切に使用するか、管理者が後のリビジョンを削除することで、常にこれらの古いリビジョンに復元できます。
一般に、それはかなり安全ですが、アクセス制御を見てください: http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.serverconfig.httpd.authz
注: Greg がほのめかしたように、ローカル リポジトリを使用する場合は、クライアントがファイル システムに直接アクセスしてリポジトリにアクセスできるため、少し複雑になります。基本的に、Subversion を信頼する必要があります。
クライアントがレポジトリの復元を必要とする何らかの方法でレポジトリを破壊できる場合、Subversion 関係者はそれを非常に深刻なバグと見なしています。
バグトラッカーをざっと見てみると、リポジトリ破損のバグがときどきあることがわかりますが、バグがなければ、クライアントがリポジトリを完全に破壊することはできません。