私たちは仕事で SCM に SVN を喜んで使用しています。現在、コードと同じ SVN リポジトリにバイナリ アセットがあります。SVN は非常に大きなファイルをサポートします (メモリ使用量を適切に保つために「ストリーム的に」送信します) が、すべてが遅くなります。アセットのバージョニングが遅いことは問題ありませんが、テキスト操作が遅いことは実際には受け入れられません。
現在、アセットは /trunk/release の下にあります (多数の /trunk/projects と並んでいます)。それらを別のリポジトリに保管する必要がありますか? 他にどのような最適化を行うことができますか? 約 1 GB の資産があり、成長しています。
すでに使用している最適化については言及していません。bsdfs を使用している場合は、fsfs に切り替えるとパフォーマンスが向上するかどうかを確認してください。多数のリビジョンがある場合は、サーバー上でより新しいバージョンに切り替え、リポジトリを 1.5 形式に変換します。
IMNSHO では、プロジェクト間でリビジョン番号を別々に保持する目的だけであれば、各プロジェクトを独自のリポジトリに保持することをお勧めします。プロジェクト foo が 6 か月間変更されていないが、プロジェクト bar が活発に開発されている場合、なぜ foo の現在のリビジョン番号が変更され続ける必要があるのでしょうか。2 つが密結合している場合 (共通のライブラリを共有している場合など) はおそらく例外ですが、その場合でも、ライブラリも独自のプロジェクトにする必要があります。
バイナリ アセットはまったく変化していませんか、それとも静的ですか? それらが静的である場合、リポジトリにまったく入れたくないかもしれません (そこに小さなプレースホルダーを残しておいてください)。
おそらくあなたが得ようとしている最良の答えは、バイナリファイルを別のディレクトリに置き、スペアディレクトリ機能を使用してそれらを管理することです-つまり、必要になるまでファイルをチェックアウトしないでください。その後、すべての操作はバイナリではなくソースファイルで行われます。
または、同じメカニズムを使用してコミットまたは更新することもできます。作業コピーを更新する代わりに、「リビジョンに更新」を使用し、HEADと減少した深さを指定して、バイナリディレクトリが更新されないようにすることができます（必要になるまで）に）。
リポジトリを「svnadminpack」することもできます。これにより、サーバー側のパフォーマンスが向上します。