30

かなり大きな SVN リポジトリがあります。コードを追加すればするほど、SVN の更新に時間がかかります。さまざまな Web サイトのFCKeditorsvn:externalsなどのいくつかのプロジェクトで繰り返されたフォルダーに追加しました。これは役に立ちましたが、それほどではありませんでした。

更新時間を短縮し、SVN 速度を向上させる最善の方法は何ですか?

4

12 に答える 12

14

古いSVNリポジトリ（またはまったく新しいが、最適にセットアップされていない）の場合は、古いBDBスタイルのリポジトリデータベースを使用している可能性があります。 http://svn.apache.org/repos/asf/subversion/trunk/notes/fsfsには、新しいものに関するメモがあります。あるものから別のものに変更するのはそれほど難しいことではありません-履歴全体をダンプし、ファイルシステムの新しいsvn形式で再初期化してから再インポートします。同時に、リポジトリダンプをフィルタリングして、役に立たない情報のチェックイン全体を削除することも役立つ場合があります（たとえば、誰かがチェックインした20MB以上のtarballファイルを削除しました）。

一般的な速度に関する限り、OSベースのキャッシング用の高品質（高速）ハードドライブと追加メモリは、SVNの動作速度を上げるという点で失敗することはほとんどありません。

クライアント側では、外部リポジトリマシンへのSSHアクセス用にPuttyAgentを介してtortoisesvnを設定している場合は、SSH圧縮を有効にすることもできます。これも役立ちます。

編集： SVN v1.5にはfsfs-reshard.pyツールもあり、FSFSベースのsvnリポジトリをいくつかのディレクトリに分割できます。これらのディレクトリ自体を異なるドライブスピンドルにリンクできます。何千ものリビジョンがある場合、それも役立ちます-何千ものファイルの中から1つのファイルを見つけるのに時間がかかる場合（そして、IOwait時間を調べることでそれが問題かどうかを判断できます）

于 2008-09-15T18:09:32.250 に答える
10

作業コピーコードを含むフォルダのウイルスチェックを無効にします。これにより、更新が2倍速くなりました。

于 2010-02-02T22:35:01.610 に答える
5

本当の答えではありませんが、svn が I/O 負荷が高い理由の 1 つは、.svn/text-base ディレクトリに各ファイルの余分なコピーを 1 つ格納するという事実であることを知ることは興味深いかもしれません。これにより、ローカル差分操作が高速になりますが、多くのハード ディスク スペースと I/O が消費されます。

http://subversion.tigris.org/issues/show_bug.cgi?id=525に詳細があります。

于 2008-09-15T18:07:53.737 に答える
4

1 つのリポジトリに複数のプロジェクトがあるようです。適切な場所でそれらを分割すると、大きな後押しが得られます。

Git は、変更を保存/処理する方法により、Subversion よりもはるかに高速であると思われますが、直接の経験はありません。

于 2008-09-15T17:57:04.713 に答える
3

一般的なパフォーマンスの調整がいくつかあります。SVNはI/Oが非常に重いため、より高速なハードディスクをオプションとして使用できます（両端）。サーバーにメモリを追加します。クライアントにデフラグされたハードディスクがあることを確認します（Windowsの場合）。

どのアクセス方法を使用するかも重要です。（file：///アクセスを使用して）リモートファイルシステムに保存されたリポジトリは、svnserveまたはmod_svnを使用したApacheよりもはるかに低速になります。単純なファイル共有にリポジトリがある場合は、後者のいずれかを使用することを検討してください。

于 2008-09-15T17:59:45.333 に答える
2

サーバーへの接続が可能な限り高速であることを確認してください（ギガビットイーサネット）。サーバーのアレイに高速ディスクがあることを確認してください。そしてもちろん、必要なものだけをチェックしてください。

于 2008-09-15T18:00:09.200 に答える
2

デフォルトでは、TotoiseSVN はバックグラウンドでファイルの変更を確認しますが、それによってマシンが遅くなることがわかりました。すべてを除外するように構成を変更し、チェックアウトしたディレクトリのみを含めました。バックグラウンド チェックをオフにすることもできます。これらの設定は両方とも、アイコン オーバーレイ設定ノードにあります。

于 2008-09-15T21:33:35.520 に答える
1

コード ベースをいくつかの兄弟モジュールに分割し、Ant スクリプトを作成して、1 人の開発者が他のモジュールで何が起こっているかをあまり気にすることなく、一度に 1 つのモジュールで作業できるようにしました。

  • 最上位のビルド スクリプトは、すべてのモジュールのビルド スクリプトをトリガーします
  • 外部ライブラリはSubversion に保存されるのではなく、Apache Ivy を使用してネットワーク ドライブから取得されます。(社内の Maven リポジトリのように考えてください)。
  • モジュール間の依存関係も Ivy を使用して管理されます。

通常、開発者はツリー全体を週に数回更新する必要がありますが、ランチ/コーヒー ブレークに行く前に簡単に行うことができます。

于 2008-09-15T20:50:12.037 に答える
1

私自身の経験 (つまり、実際のテストではありません) で、特に SVN リポジトリ サーバーがリモートの場合、externals を使用すると速度が低下するように見えることがわかりました。複数の場所に重複したコード (FCK エディターなど) がある場合、それらのファイルを同期させて管理しやすくすることが更新速度よりも重要であるため、私はエクスターナルの使用に固執する傾向があります。代わりに重複したコードで。(Windows XP を使用している場合は、ジャンクション ポイントを使用できます)。

于 2008-09-15T19:12:16.797 に答える
1

読み取りアクセス権を使用する (つまり、読み取りアクセスを特定の個人/グループに制限する) と、リポジトリが大幅に遅くなります。特に、Windows ドメインに対してなど、特別な方法で認証が行われる場合。もちろん、同じことが書き込みアクセス権にも当てはまりますが、書き込みは読み取りよりも頻度が低くなります。また、書き込みアクセスを制限することは、読み取りアクセスを制限することよりも重要な場合があります

于 2013-01-10T10:42:43.110 に答える
0

リポジトリのルートに多くのフォルダーがあり、ローカル コピーがリポジトリを反映している場合は、モノリシックなローカル コピーを多数の分離されたダウンロード可能なフォルダーに分割し、これらのフォルダーも個別に更新してみてください。1 つの大きなフォルダーよりもはるかに高速です。

于 2008-09-15T18:15:31.690 に答える