制御ソフトの成果物、ファームウェア、CADデータ、図面、Excelの設計台帳——。こうした大容量のバイナリ資産をSVN（Subversion）で管理していると、リポジトリが年々膨らみ、バックアップも初回のチェックアウトも重くなっていきます。
結論から言えば、SVNはもともと大容量に強い仕組みです。必要なディレクトリだけを手元に取り出せるため、数百GB〜TB級でも作業コピーを軽く保てます。問題は、運用次第で差が出ることです。そして肥大化対策の鍵は、トラブルが起きてからではなく「入れる前の設計」にあります。
この記事では、SVNを10年以上ホスティングサービスとして提供してきた私たちが、大容量リポジトリを破綻させないための実践的なコツを整理します。
ホスティング選定で大容量対応をどう見るかは、「SVNホスティングの選び方｜大容量・監査対応の8チェック」でも扱っています。
なぜSVNリポジトリは肥大化するのか
リポジトリが膨らむ主因は、2つあります。
1. バイナリは差分が効きにくい
SVNは、テキストファイルなら変更箇所の差分だけを効率よく記録します。しかし、画像・動画・圧縮済みファイル・多くのバイナリ形式は差分が効きにくく、変更のたびにファイルがまるごと近い容量で積み上がりやすいのです。大きなファイルを頻繁に更新するほど、容量は加速度的に増えます。
2. 履歴は消えない
バージョン管理の本質ですが、一度コミットしたファイルは、後で削除しても履歴には残り続けます。「間違って巨大なファイルを入れてしまった」場合でも、削除しただけでは容量は減りません。履歴から完全に取り除くには、リポジトリを作り直す大がかりな作業（svnadmin dump／load と svndumpfilter を使った再構築）が必要で、止まりやすく現実には推奨できません。
この2点があるからこそ、「入れてから対処する」のではなく「入れる前に設計する」ことが、決定的に重要になります。
大原則：トラブルが起きる前に設計する
以下で具体策を挙げますが、根底にある考え方は一つです。何を・どこに・どの単位で入れるかを、運用が始まる前に決めておくこと。これだけで、後から苦労する肥大化の大半は防げます。
対策1：リポジトリ／ディレクトリを用途で分ける
すべてを一つの巨大リポジトリに詰め込むと、初回チェックアウトもバックアップも重くなります。
- 巨大なバイナリ資産と、頻繁に変更するコードを分ける：性質の違うものを別リポジトリ（または明確に別ディレクトリ）にすると、扱いが軽くなります
- プロジェクト・製品単位で分ける：関係のない人まで全体を取得しなくて済みます
この分け方そのものが、後述の「部分チェックアウト」を効かせる土台になります。
対策2：「入れないもの」を決める
容量の多くは、本来入れる必要のないファイルが占めていることがあります。
- ビルド成果物・中間生成物は入れない：ソースから再生成できるものは、バージョン管理の対象外にします
svn:ignoreを活用する：管理対象に含めたくないファイル・フォルダを指定しておくと、うっかりコミットを防げます- 成果物の置き場ルールを決める：「どの成果物を、どのディレクトリに、どの粒度で残すか」をチームで合意しておきます
「とりあえず全部入れる」をやめるだけで、肥大化のスピードは大きく変わります。
対策3：バイナリはロック運用にする（svn:needs-lock）
マージできないバイナリファイル（Excel・図面・CADなど）は、複数人が同時に編集すると上書き事故が起きます。
SVNには svn:needs-lock 属性があります。この属性を付けたファイルは、普段は読み取り専用になります。そのため、編集する人は先にロックを取得することが強制され、「気づかず同時編集していた」という事故を仕組みで防げます。大容量バイナリを扱う現場では、ロック運用を標準にしておくと安全です。
ロックの基本操作は、「TortoiseSVNの使い方」のロックの節で解説しています。
対策4：部分チェックアウトで作業コピーを軽く保つ
SVNの大きな強みが、リポジトリ全体ではなく、必要な階層だけを取り出せることです。
- TortoiseSVNなら、チェックアウト時に取得する深さ（depth）を指定できます
- コマンドなら
svn checkout --depthや、後からsvn update --set-depthで範囲を調整できます
自分が関わるディレクトリだけを取得すれば、リポジトリ全体が数百GBあっても、手元の作業コピーは軽いままです。全履歴を各端末へ複製するGitとの、運用上の大きな違いが、ここに表れます。
対策5：バックアップと容量の現実に備える
リポジトリが大きくなるほど、バックアップ自体が重く・長くなります。
自社運用の場合、容量が逼迫するたびにディスクを増設し、肥大化したリポジトリのバックアップ時間とにらめっこすることになります。災害に備えて遠隔地にもバックアップを持とうとすれば、負担はさらに増します。
ここは、クラウドのSVNホスティングが効く領域です。容量の増設を気にせず、地理的に離れた拠点へ分散してバックアップする体制も、サービス側で備えられます。大容量運用の「容量とバックアップの悩み」を、丸ごと預けられるわけです（→SVNのバックアップとBCP｜障害・災害から守る運用）。
容量とバックアップの悩みを、丸ごと預ける。
tracpathは大容量リポジトリに対応したSVN・Gitクラウドホスティング。容量の増設や遠隔地バックアップの手間なく、数百GB〜TB級の資産を運用できます。
→ 大容量リポジトリの運用相談（無料） ／ → まずは無料で試す
公平に：Git LFSという選択肢
公平に書きます。大容量バイナリの管理には、Git側にも Git LFS（Large File Storage） という仕組みがあります。Gitを使いたい事情があるなら、選択肢になります。
ただし、LFSは「Gitに大容量を無理なく載せるための追加の仕組み」であり、専用のサーバーや運用ルールが別途必要になります。もともと大容量資産を「必要な分だけ取得」で素直に扱えるSVNのシンプルさとは、運用の重さが異なります。すでにSVNで大容量資産を運用しているなら、その強みをそのまま活かすのが合理的です（仕組みの違いは「SVNとGitの違いと使い分け」を参照）。
まとめ
| コツ | 要点 |
|---|---|
| 肥大化の原因を知る | バイナリは差分が効きにくい／履歴は消えない → 入れる前の設計が重要 |
| リポジトリを分ける | 巨大バイナリと頻繁変更コードを分離 |
| 入れないものを決める | 生成物は対象外・svn:ignore・置き場ルール |
| ロック運用 | svn:needs-lock で上書き事故を防止 |
| 部分チェックアウト | --depth で作業コピーを軽く保つ |
| 容量・バックアップ | 増設・遠隔分散はクラウドに任せられる |
- SVNはもともと大容量に強い。必要な分だけ取得できるのが本質的な強み
- 肥大化対策の本丸は「入れる前の設計」。一度入れた履歴は消えない前提で設計する
- バイナリはロック運用、作業コピーは部分チェックアウトで軽く保つ
- 容量増設とバックアップの負担は、クラウドホスティングで手放せる
容量を気にせず、大容量資産をそのまま。
tracpathは大容量リポジトリに対応したSVN・Gitクラウドホスティング。容量の増設や遠隔地バックアップの手間なく、数百GB〜TB級の資産を運用できます。国内サーバー・ISMS認証。
→ 大容量リポジトリの運用相談（無料） ／ → 容量の簡易診断はこちら
関連記事
この記事の著者
株式会社オープングルーヴ ／ tracpath編集部
2004年よりソフトウェア開発の現場を支援。SVN・Gitのクラウドホスティングサービス「tracpath」を提供し、製造業・業務システム開発企業のバージョン管理・移行を多数支援。ISMS（ISO 27001／27017）認証取得。
