SVN通过svn:externals实现跨项目依赖管理，需锁定版本号、引用tags目录、统一目录结构及权限控制以确保可追溯、可锁定、可复现。
SVN本身不内置项目依赖管理机制，但可通过externals（外部定义）和统一目录结构设计实现跨项目的版本化引用与协同开发。关键不是“自动解决依赖”，而是让依赖关系可追溯、可锁定、可复现。
用 externals 管理跨项目依赖
当项目A需要复用项目B的某段代码（如公共组件库、基础框架），不建议直接拷贝，而应通过 svn:externals 属性建立受控引用。
- 在项目A的
trunk/lib/目录下执行：svn propset svn:externals "common https://svn.example.com/repos/project-b/trunk/src/common@12345" .
其中@12345锁定到项目B的特定修订版本，避免因上游变更导致构建失败 - 支持三种引用方式：绝对URL（推荐）、相对URL（同仓库内）、带版本号的固定引用（最安全）
- 每次
svn update会自动拉取 externals 内容；检出时需加--force参数才能同步 externals - 注意：externals 不支持递归嵌套（即不能在 externals 目录里再设 externals），也不参与 commit 原子性——主项目提交成功，externals 可能未更新
多项目共存的目录结构优化
推荐采用“单根多仓”模式：所有项目仓库置于同一父目录下，由 svnserve 统一托管，既保持隔离又便于运维。
- 物理布局示例：
/var/svn/repos/<br>├── project-a/<br>│ ├── trunk/<br>│ ├── branches/<br>│ └── tags/<br>├── project-b/<br>│ ├── trunk/<br>│ ├── branches/<br>│ └── tags/<br>└── shared-utils/<br> ├── trunk/<br> └── tags/
- 启动服务时指定根路径：
svnserve -d -r /var/svn/repos，客户端访问地址为svn://server/project-a，无需暴露完整路径 - 共享模块（如工具库）单独建仓，供多个项目通过 externals 引用；避免将其塞进某个项目仓库，否则权限和生命周期被绑定
权限与版本协同策略
依赖管理有效性的前提是权限清晰、版本可锚定。
- 在全局
authz文件中按项目粒度授权：[groups]<br>devs = alice,bob<br>[project-a:/]<br>@devs = rw<br>[shared-utils:/tags/]
只开放 tags 目录只读，防止误改稳定版本 - 约定 tag 命名规范（如
v2.1.0-release），所有 externals 必须引用tags/下路径，禁止指向 trunk 或分支——这是保证依赖稳定的核心纪律 - 发布新版本时，先在 shared-utils 打 tag，再批量更新各项目 externals 属性并提交，形成可审计的升级流水线
规避常见陷阱
实际落地中最容易踩坑的几个点：
-
不锁版本号：externals 缺少
@REV导致每次 update 拉最新代码，引发隐性兼容问题 - 混用仓库层级：把 project-b 的 trunk 当作依赖引入，等于把开发中的不稳定代码暴露给所有下游项目
-
忽略 externals 更新：开发者执行
svn update后忘记svn update --set-depth exclude lib/ && svn update lib/来刷新 externals（尤其在属性变更后） - 权限过度开放：允许普通开发者对 shared-utils 的 trunk 具有写权限，破坏了“共享模块由专人维护”的契约
