協力会社には設計書だけを渡し、社内の開発者にはソースコードの更新を許可したい。こうした場合は、SVNのパスベース認可で、リポジトリ内のディレクトリごとに読取り・書込みの範囲を設定します。
まず、誰がどの資料を使うかを一覧にします。設定ファイルを変更した後は、許可した操作と、許可していない操作の両方を利用者の権限で試してください。
ログインとアクセス許可を分けて考える
認証は、アクセスした人の本人確認です。認可は、その人に許す操作を決めることです。ログインできても、すべてのフォルダを読めるとは限りません。
図では、社員は開発用フォルダを更新でき、協力会社は共有用フォルダだけを読める構成を示します。
図：社員は開発用と共有用フォルダを更新でき、協力会社は共有用のみ読める権限の例。画像を開くと拡大できます。
権限設定で制限できるのはサーバー経由のアクセスです。既に取得された作業コピーや、別の場所に転記された情報を回収する機能ではありません。ディレクトリ名や変更理由にも、共有相手へ出せない情報を含めない運用が必要です。
権限は対象と操作の組で記録する
| 対象 | 社内開発者 | 協力会社 |
|---|---|---|
| 開発用フォルダ | 読取り・書込み | 許可しない |
| 共有用フォルダ | 読取り・書込み | 読取りのみ |
| 管理資料 | 指定した担当者のみ | 許可しない |
この表は設計例です。実際には担当業務に合わせてグループを分け、アカウントの追加・削除を誰が承認するかも決めます。利用者が複数のグループに所属する場合は、その組合せで意図より広い権限にならないかを確認します。
authzによる設定例
自社でサーバーを管理する場合、パスベース認可の設定にはauthzファイルを使えます。ホスティングでは管理画面や提供元への依頼で設定する場合もあるため、利用サービスの方法に従ってください。
[groups]
developers
=
alice, bob
partner
=
carol
[repository:/]
*
=
[repository:/development]
@developers
=
rw
[repository:/shared]
@developers
=
rw
@partner
=
r
repositoryは実際のリポジトリ名、利用者名は説明用の例です。rは読取り、rwは読取りと書込みを表します。上の例はルートでアクセスを許可せず、必要なパスに許可を追加しています。
サーバー側でパスベース認可を有効にする設定も必要です。親からの継承、個人の設定、所属グループによって結果が変わるため、空欄の指定が常に他の許可を打ち消すと考えないでください。
設定後に試す操作
- 社内開発者として、開発用・共有用フォルダを取得し、検証用ファイルを更新する。
- 協力会社として、共有用フォルダを取得でき、書き込めないことを確認する。
- 協力会社として、開発用フォルダへの直接URL指定や履歴の参照を試す。
- 許可対象外の利用者と匿名アクセスでも確認する。
- 実行した利用者、パス、操作、結果を記録する。
閲覧用Web画面とSVNクライアントの両方がある場合は、それぞれで確認します。設定変更は検証環境で試し、誤った場合に戻せるよう変更前の設定を保管します。
入退社と案件終了に合わせて見直す
権限の承認記録には、利用者、対象パス、操作範囲、利用期限を残します。異動、退職、協力会社との契約終了を権限変更のきっかけにし、不要なアカウントとグループ所属を整理してください。
権限一覧は運用説明の資料になりますが、それだけで監査の要求を満たすとは限りません。必要な変更履歴や承認記録は、取引先の要求に合わせて残します。
相談時に伝えること
tracpathでの権限管理を検討する場合は、共有したい資料、利用者の区分、読取り・書込みの範囲をお知らせください。提供機能で設定できる範囲をご案内します。
参考資料
確認日：2026年10月6日。 SVN Bookの参照先は1.7系列の説明です。実際の設定・操作は、使用中のバージョンと提供サービスの仕様も確認してください。
関連記事
この記事の著者
株式会社オープングルーヴ／tracpath編集部。バージョン管理サービスtracpathを提供。
