過去に納品したシステムの調査では、当時のソースだけでなく、設計書、設定、依存ライブラリ、ビルド方法が必要になることがあります。リポジトリを残していても、対象版と関連資料が分からなければ、調査を始めるまでに時間がかかります。
この記事は、多数の案件をSVNで保守する場合の整理方法を説明します。特定企業の導入成果や、移行による費用削減を示す事例ではありません。
利用状態と保存要件を分けて管理する
開発中、保守中、更新停止という利用状態を記録します。更新していないことだけを理由に削除せず、契約や社内要件から保存対象と期間を確認してください。
図：リポジトリ一覧を開発中、保守中、保存要件を確認する対象に分ける図。画像を開くと拡大できます。
図の「保存要件を確認」は削除の指示ではありません。保存を続ける場合と廃止できる場合を、根拠に沿って判断するための区分です。
リポジトリ台帳に残す情報
| 項目 | 記録する内容 |
|---|---|
| 識別 | 案件名、リポジトリ、対象パス、担当者 |
| 利用状態 | 開発中、保守中、更新停止など |
| 対象版 | 納品版・保守版のパスとリビジョン |
| 関連資料 | 設計書、設定、変更票、試験記録の保管先 |
| 再現環境 | ビルドツール、ライブラリ、手順、使用条件 |
| 保存条件 | 保存の根拠、期限、廃止判断者 |
| 取出し | 保管先、アクセス方法、復元確認日と結果 |
保存期間や復元に求められる時間は、案件ごとの契約・保守条件で確認します。「保守案件だから永久保存」といった一律の決め方は避けてください。
過去版を取り出せるか試す
代表となる納品版を選び、担当者以外が台帳と手順から必要なファイルを取得できるかを確認します。再ビルドが必要な案件では、ビルドと生成物の照合も試します。
外部ライブラリの配布終了、古いツールのライセンス、OSの互換性など、リポジトリだけでは解決しない条件も記録します。古いソフトウェアを動かす必要がある場合は、現在の業務環境から分離した検証方法を検討します。
更新を止めるときも権限を確認する
更新停止の案件は、必要に応じて利用者の書き込みを禁止し、保守で再開する場合の承認手順を決めます。読取り権限も、担当外の案件まで広がっていないかを確認してください。
リポジトリを別の保管先へ移す場合は、データ形式、必要な設定、復元方法、保管先へのアクセスを記録します。バックアップファイルが存在することと、必要な版を復元できることは別です。
保存容量と運用費を見直す
不要な作業用キャッシュや再生成可能な成果物を、今後も同じ場所で管理する必要があるかを確認します。過去の履歴から削除する作業は、リビジョンや外部参照へ影響するため、単なる容量整理として実施しないでください。
容量増加、バックアップ、復元確認、問い合わせ対応にかかる費用を記録します。ホスティングの場合も、追加容量や復元依頼、契約終了時の取出し条件を含めて見積もります。
移行しても自社に残る作業
移行先の提供元が基盤を保守する場合でも、保存期間の判断、アクセスの承認、納品版と関連資料の対応は自社で管理します。誰がどこまで行うかを契約と手順で確認してください。
移行時は、履歴、属性、権限、過去版の取出しを検証し、利用再開前にバックアップと復元方法を確認します。旧環境は保存要件と受け入れ結果に従って廃止します。
最初に確認する案件を選ぶ
近く保守対応が必要な案件や、担当者の変更が予定されている案件から、台帳と取出し手順を確認します。その結果を他の案件にも適用し、保存対象を整理してください。
参考資料
確認日：2026年10月6日。 SVN Bookの参照先は1.7系列の説明です。実際の設定・操作は、使用中のバージョンと提供サービスの仕様も確認してください。
関連記事
この記事の著者
株式会社オープングルーヴ／tracpath編集部。バージョン管理サービスtracpathを提供。
