かなり大きなSVNリポジトリがあります。 SVNの更新を行うには、コードを追加するほど時間がかかります。さまざまなWebサイトの FCKeditor などの一部のプロジェクトで繰り返されるフォルダーにsvn:externals
を追加しました。これは役に立ちましたが、それほどではありませんでした。
更新時間を短縮し、SVN速度を上げるための最良の方法は何ですか?
古い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ベースのsvnリポジトリをに分割するのに役立つ fsfs-reshard.py ツールもあります。いくつかのディレクトリ-それ自体を異なるドライブスピンドルにリンクすることができます。何千ものリビジョンがある場合、それも役立ちます-何千ものファイルの中から1つのファイルを見つけるのに時間がかかる場合(そして、IOwait時間を調べることでそれが問題かどうかを判断できます)
作業コピーコードを含むフォルダのウイルスチェックを無効にします。これにより、更新が2倍速くなりました。
実際には答えではありませんが、svnがI/Oを多用する理由の1つは、各ファイルの1つの余分なコピーを.svn/text-baseディレクトリに格納するという事実です。これにより、ローカルの差分操作が高速になりますが、ハードディスク領域とI/Oが大量に消費されます。
http://Subversion.tigris.org/issues/show_bug.cgi?id=525 詳細があります。
1つのリポジトリに複数のプロジェクトがあるようです。必要に応じてそれらを分割すると、大きな後押しが得られます。
おそらく、Gitは変更を保存/処理する方法のためにSubversionよりもはるかに高速ですが、私はそれを直接経験したことがありません。
一般的なパフォーマンスの調整がいくつかあります。 SVNはI/Oが非常に重いため、より高速なハードディスクをオプションとして使用できます(両端)。サーバーにメモリを追加します。クライアントにデフラグされたハードディスクがあることを確認してください(Windowsの場合)。
どのアクセス方法を使用するかも重要です。 (file:///アクセスを使用して)リモートファイルシステムに保存されたリポジトリは、svnserveまたはmod_svnを使用したApacheよりもはるかに遅くなります。単純なファイル共有にリポジトリがある場合は、後者のいずれかを使用することを検討してください。
サーバーへの接続が可能な限り高速であることを確認してください(ギガビットイーサネット)。サーバーのアレイに高速ディスクがあることを確認してください。そしてもちろん、必要なものだけをチェックしてください。
TotoiseSVNはデフォルトでファイルの変更をバックグラウンドで確認しますが、これによりマシンの速度が低下することがわかりました。すべてを除外し、チェックアウトがあるディレクトリのみを含めるように構成を変更しました。バックグラウンドチェックをオフにすることもできます。これらの設定は両方とも、アイコンオーバーレイ設定ノードにあります。
特に多くの外部の場合、遅いsvn操作がDNSに関連していることがあります。 svnは、相対的なものであっても、すべてのsvn:externalごとにDNSルックアップを実行するようです。 svnサーバーのホスト名を/ etc/hostsに追加するか、resolv.confを修正すると便利です。
私自身の経験で(つまり、実際のテストではない)、特にSVNリポジトリサーバーがリモートの場合、外部を使用すると物事を遅くします。複数の場所で重複したコード(FCKエディターなど)がある場合、それらのファイルの同期と管理を維持することが更新速度よりも重要であるため、外部の使用に固執する傾向があります-ただし、シンボリックリンクを使用してもたらすことを検討できます代わりに重複したコードで。 (Windows XPを使用している場合は、 ジャンクションポイント を使用できます)。
読み取りアクセス権を使用すると(つまり、特定の個人/グループへの読み取りアクセスを制限すると)、リポジトリの速度が大幅に低下します。特に、認証が特別な方法で行われる場合、たとえばWindowsドメインに対して。もちろん、書き込みアクセス権についても同じことが言えますが、書き込みは読み取りよりも頻度が低くなります。また、書き込みアクセスを制限することは、読み取りアクセスを制限することよりも重要になる可能性があります
コードベースをいくつかの兄弟モジュールに分割し、Antスクリプトを記述して、1人の開発者が他のモジュールで何が起こっているかをあまり気にせずに一度に1つのモジュールで作業できるようにしました。
通常、開発者は週に2、3回ツリー全体を更新する必要がありますが、昼食やコーヒーブレイクに行く前に簡単に更新できます。
リポジトリのルートに多くのフォルダがあり、ローカルコピーがリポジトリを反映している場合は、モノリシックローカルコピーを多数の個別のダウンロード可能なフォルダに分割し、これらのフォルダも個別に更新してみてください。1つの大きなフォルダよりもはるかに高速です。