私のプロジェクトは現在、1 日に数百の新しいリビジョンを取得する svn リポジトリを使用しています。リポジトリは Win2k3 サーバー上にあり、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 (最新) リビジョンはフルテキストですが、以前のリビジョンは head に対する一連の差分として構築されます。これは、各コミット後に以前のリビジョンを再計算する必要があることを意味します。
詳細情報: http://svn.apache.org/repos/asf/subversion/trunk/notes/skip-deltas
PS 私たちのレポは約 20GB で、約 35,000 のリビジョンがあり、パフォーマンスの低下は見られません。
Subversion は、最新バージョンを全文として保存し、後方参照の差分を付けます。これは、頭への更新が常に高速であることを意味し、段階的に支払うものは、履歴をどんどんさかのぼります。
私は個人的に、実際のプロジェクトで 80K LOC を超えるコードベースを持つ Subversion リポジトリを扱ったことはありません。私が実際に持っていた最大のリポジトリは約 1.2 ギガでしたが、これにはプロジェクトが使用するすべてのライブラリとユーティリティが含まれていました。
日常の使用にはそれほど影響はないと思いますが、さまざまなリビジョンに目を通す必要があるものは、少し遅くなる可能性があります。目立たないこともあります。
ここで、システム管理者の観点から、パフォーマンスのボトルネックを最小限に抑えるのに役立つことがいくつかあります。Subversion はほとんどがファイルベースのシステムであるため、次のようにすることができます。
これはあなたの状況ではやり過ぎかもしれませんが、それは私が他のファイル集約型アプリケーションに対して通常行ったことです。
もしあなたが Subversion を「超えてしまった」なら、Perforceがあなたの次のステップアップになるでしょう。非常に大規模なプロジェクト向けの最速のソース管理アプリです。
ギガバイトに相当するコードとバイナリを含む Subversion サーバーを実行しており、最大で 2 万を超えるリビジョンがあります。まだ減速はありません。
Subversionは、2つのリビジョン間のデルタ（差異）のみを保存するため、特にコード（テキスト）のみをコミットし、バイナリ（画像とドキュメント）をコミットしない場合は、多くのスペースを節約できます。
さらに、svnを使用した非常に大きなプロジェクトをたくさん見て、パフォーマンスについて文句を言うことはありませんでした。
たぶんあなたはチェックアウト時間について心配していますか？それなら、これは本当にネットワークの問題になると思います。
ああ、私は2Gb以上のもの（コード、imgs、ドキュメント）を使用してCVSリポジトリに取り組んだことがあり、パフォーマンスの問題は発生していません。svnはcvsの大幅な改善であるため、心配する必要はないと思います。
それがあなたの心を少し楽にするのに役立つことを願っています;）
私たちの転覆が老化によって遅くなったとは思いません。現在、数テラバイトのデータがあり、ほとんどがバイナリです。毎日最大 50 ギガバイトのデータをチェックアウト/コミットします。合計で、現在 50000 のリビジョンがあります。ストレージ タイプとして FSFS を使用しており、直接 SVN: (Windows サーバー) または Apache mod_dav_svn (Gentoo Linux サーバー) 経由でインターフェイスしています。
比較できるパフォーマンス比較のためにクリーンなサーバーをセットアップしたため、これにより svn が時間の経過とともに遅くなることは確認できません。大幅な劣化は測定できませんでした。
しかし、私たちのサブバージョンはデフォルトでは非常に遅く、別のコンピュータ システムで試したように、明らかにサブバージョンそのものであると言わざるを得ません。
いくつかの不明な理由により、subversion はサーバーの CPU が完全に制限されているようです。1 つのサーバー CPU コアが完全に使い果たされるため、チェックアウト/コミット速度はクライアントあたり 15 ～ 30 メガバイト/秒に制限されています。これは、完全なサーバー (~5 テラバイト、50000 リビジョン) とほぼ空のリポジトリ (1 ギガバイト、5 リビジョン) の場合と同じです。圧縮を 0 = オフに設定するようなチューニングを行っても、これは改善されませんでした。
当社の高帯域幅 (～1 ギガバイト/秒を提供) FC アレイはアイドル状態になり、他のコアはアイドル状態になり、ネットワーク (現在、クライアント用に 1 ギガビット/秒、サーバー用に 10 ギガビット/秒) もアイドル状態になります。アイドリングではありませんが、使用可能な容量の 2 ～ 3% しか使用されていない場合、アイドリングと呼びます。
すべてのコンポーネントがアイドル状態になっているのを見るのは楽しいことではなく、作業コピーがチェックアウトまたはコミットされるのを待つ必要があります。基本的に、チェックアウト/コミット中に常に1つのCPUコアを完全に消費することにより、サーバープロセスが何をしているのかわかりません。
しかし、私は転覆を調整する方法を見つけようとしています。これが不可能な場合は、別のシステムに切り替える必要があるかもしれません。
したがって: 回答: SVN のパフォーマンスは低下しません。最初は低速です。
もちろん、(高い) パフォーマンスを必要としない場合は問題ありません。ところで。上記はすべて、最新の安定バージョンの Subversion 1.7 に適用されます
速度が低下する可能性がある唯一の操作は、複数のリビジョンから情報を読み取るものです (SVN Blame など)。
よくわかりません.....Centos5.2でApacheを使用してSVNを使用しています。正常に動作します。リビジョン番号は8230でした...そしてすべてのクライアントマシンでコミットが非常に遅いため、1kbのファイルを少なくとも2分待たなければなりませんでした。私は大きなファイルサイズを持たない1つのファイルについて話している。
次に、新しいリポジトリを作成しました。revから開始。1.これで問題なく動作します。速い。svnadmincreatexxxxxxを使用しました。FSFSなのかBDBなのか確認しませんでした。
ワークフローの改善を検討する必要があるかもしれません。
これらの条件でリポジトリにパフォーマンスの問題があるかどうかはわかりませんが、正常なリビジョンに戻ることができます。
あなたの場合、検証プロセスを含めることができます。そのため、チームはチーム リーダー リポジトリでコミットし、それぞれが読み取り専用のクリーンな会社リポジトリにコミットするチーム マネージャー リポジトリにコミットします。その段階で、どのコミットを一番上に置く必要があるかを明確に選択しました。
このようにして、誰もが履歴を簡単に参照できるクリーンなコピーに戻ることができます。マージははるかに簡単で、開発者は好きなだけ混乱をコミットできます。