多くの修正後のSVNパフォーマンス
私のプロジェクトは現在、1日あたり数百の新しいリビジョンを取得するsvnリポジトリを使用しています。リポジトリはWin2k3-serverにあり、Apache/mod_dav_svnを介して提供されます。
修正が多すぎるために、時間の経過とともにパフォーマンスが低下するのではないかと今は恐れています。
この恐れは妥当ですか？
すでに1.5へのアップグレードを計画しているため、1つのディレクトリに数千のファイルが存在しても、長期的には問題ありません。
Subversion onは、2つのリビジョン間の差分（差分）を保存するため、特にコード（テキスト）のみをコミットし、バイナリ（イメージとドキュメント）をコミットしない場合は、多くのスペースを節約できます。
これは、ファイルfoo.bazのリビジョン10をチェックアウトするために、svnがリビジョン1を取得してから、デルタ2-10を適用することを意味しますか？
どんなタイプのレポがありますか？ FSFSまたはBDB？
（これがデフォルトなので、今のところFSFSであると仮定しましょう。）
FSFSの場合、各リビジョンは以前のリビジョンとの差分として保存されます。だから、あなたはそうだと思います、多くの修正の後、それは非常に遅くなるでしょう。
ただし、これは当てはまりません。 FSFSは、 "スキップデルタ"と呼ばれるものを使用して、以前のリビジョンであまりにも多くのルックアップを実行する必要がないようにします。
（したがって、FSFSリポジトリを使用している場合、Brad Wilsonの答えは間違っています。）
BDBリポジトリの場合、HEAD（最新）リビジョンはフルテキストですが、以前のリビジョンはヘッドに対する一連の差分として構築されます。これは、以前のリビジョンが各コミット後に再計算されます。
詳細情報： http://svn.Apache.org/repos/asf/Subversion/trunk/notes/skip-deltas
追伸私たちのリポジトリは約20GBで、約35,000のリビジョンがあり、パフォーマンスの低下は確認されていません。
Subversionは、最新バージョンをフルテキストとして、後方参照の差分とともに保存します。つまり、headへの更新は常に高速であり、追加料金を支払うことで、履歴をどんどんさかのぼることになります。
私自身は、実際のプロジェクトでは、コードベースが80K LOCを超えるSubversionリポジトリを扱っていません。私が実際に持っていた最大のリポジトリは約1.2ギグでしたが、これにはプロジェクトが使用するすべてのライブラリとユーティリティが含まれていました。
毎日の使用はそれほど影響を受けないと思いますが、異なるリビジョンを確認する必要があるものは少し遅くなるかもしれません。目立たないこともあります。
さて、システム管理者の観点から見ると、パフォーマンスのボトルネックを最小限に抑えるのに役立つことがいくつかあります。 Subversionは主にファイルベースのシステムであるため、これを行うことができます：
- 実際のリポジトリを別のドライブに置く
- 上記のドライブでsvn以外のファイルロックアプリが動作していないことを確認してください
- ドライブを少なくとも7,500 RPMにします。あなたは10,000 RPMを取得してみることができますが、それはやり過ぎかもしれません
- 全員が同じオフィスにいる場合は、LANをギガビットに更新します。
これはあなたの状況にとってはやり過ぎかもしれませんが、それは私が他のファイル集約型アプリケーションに対して通常行ってきたことです。
Subversionを「拡張」する場合は、 Perforce が次のステップになります。非常に大規模なプロジェクトの最速のソース管理アプリです。
私たちは、ギガバイト相当のコードとバイナリを備えたSubversionサーバーを実行しており、最大で2万を超えるリビジョンがあります。まだ落ち込みはありません。
私たちのSubversionは老化によって速度が低下したとは思いません。現在、数テラバイトのデータがあり、ほとんどがバイナリです。最大50ギガバイトのデータを毎日チェックアウト/コミットします。現在、合計50000のリビジョンがあります。ストレージタイプとしてFSFSを使用しており、直接SVN（Windowsサーバー）またはApache mod_dav_svn（Gentoo Linuxサーバー）を介して接続しています。
パフォーマンスを比較できるクリーンなサーバーをセットアップしたので、これによりsvnが時間とともに遅くなることを確認できません。重大な低下を測定できませんでした。
しかしながら、私は私たちのSubversionがデフォルトでめったに遅くないことを言わなければなりません、そして明らかに我々が別のコンピュータシステムで試みたようにそれはSubversion自体です。
いくつかの不明な理由により、SubversionはサーバーのCPUが完全に制限されているようです。 1つのサーバーCPUコアが完全に使い果たされるため、チェックアウト/コミットレートはクライアントあたり15〜30メガバイト/秒に制限されます。これは、ほぼ空のリポジトリ（1ギガバイト、5リビジョン）の場合と、フルサーバー（〜5テラバイト、50000リビジョン）の場合とで同じです。圧縮を0 =オフに設定するような調整では、これは改善されませんでした。
当社の高帯域幅（約1ギガバイト/秒）のFCアレイアイドル、他のコアのアイドル、およびネットワーク（現在、クライアントでは1ギガビット/秒、サーバーでは10ギガビット/秒）アイドル。本当にアイドリングではありませんが、利用可能な容量の2〜3％しか使用されていない場合は、アイドリングと呼びます。
すべてのコンポーネントがアイドリングしているのを見るのは本当に楽しいことではありません。作業コピーがチェックアウトまたはコミットされるのを待つ必要があります。基本的に、チェックアウト/コミット中に常に1つのCPUコアを完全に消費することで、サーバープロセスが何をしているのかわかりません。
ただし、Subversionを調整する方法を見つけようとしています。これが不可能な場合は、別のシステムに切り替える必要があるかもしれません。
したがって：回答：SVNはパフォーマンスを低下させず、最初は遅いです。
もちろん、（高い）パフォーマンスが必要ない場合は問題ありません。ところで上記のすべては、サブバージョン1.7最新の安定バージョンに適用されます
Subversionは、2つのリビジョン間の差分（差分）のみを保存するため、特にコード（テキスト）のみをコミットし、バイナリ（イメージとドキュメント）をコミットしない場合は、多くのスペースを節約できます。
さらに、svnを使用した非常に大きなプロジェクトをたくさん見てきましたが、パフォーマンスについて不満を言うことはありませんでした。
たぶんあなたはチェックアウト時間を心配していますか？次に、これは本当にネットワークの問題になると思います。
ああ、私は2Gb +のもの（コード、画像、ドキュメント）を使ってCVSリポジトリに取り組んできましたが、パフォーマンスの問題は一度もありませんでした。 svnはcvsの大幅な改善なので、心配する必要はないと思います。
それがあなたの心を少し楽にするのを願っています;）
遅くなる可能性が高い唯一の操作は、複数のリビジョン（SVN Blameなど）から情報を読み取るものです。