关键在于用好svn:externals的版本锁定机制，必须明确指定修订号（如@2456），避免依赖head导致意外更新；统一在根目录或libs下集中配置多行引用，修改后需执行propset、commit、update三步，并在ci中校验实际revision。
要让公共模块在多个项目中保持版本一致、避免意外更新导致构建失败，关键在于用好 svn:externals 的版本锁定机制。不是简单挂个链接，而是把“用哪个版本”这个决定固化下来。
明确指定版本号，别依赖 HEAD
默认不写版本时，SVN 会拉取最新（HEAD）代码，这看似省事，实则埋雷——别人一提交，你的项目就可能悄悄变样。
- 推荐写法：
CommonLib http://svn.example.com/libs/CommonLib@2456（@后跟具体修订号） - 命令行设置示例：
svn propset svn:externals "utils http://svn.company.com/shared/utils@1890" libs - TortoiseSVN 图形界面中，勾选“Specify revision”，手动填入数字，不要选“Head revision”
统一集中管理 externals 属性
所有外部引用尽量只在一个地方定义，通常是项目根目录或 libs/ 这类专用目录下。避免分散在多个子目录设多个 svn:externals 属性——后设的会覆盖前设的，容易漏配或冲突。
- 属性值支持多行，每行一条引用，结构清晰易维护
- 例如在
trunk/libs目录下统一配置：CommonUI http://svn.company.com/ui/CommonUI@3210<br> DataModel http://svn.company.com/model/DataModel@789<br> LoggerSDK ^/thirdparty/logger@1550
- 提交前用
svn propget svn:externals libs检查是否生效
更新与验证必须成对操作
改了 externals 属性后，不能只 commit 属性，还要主动执行 svn update，否则本地工作区不会自动拉新版本。
- 修改属性 →
svn commit→svn update是标准三步 - 更新后检查
svn status -u，确认 externals 目录状态为X，且内容实际已同步到目标版本 - CI 构建脚本中建议加一行
svn info libs/CommonLib | grep Revision，确保构建环境确实用了锁定的版本
跨仓库引用也要带版本，尤其对外部源
引用 GitHub SVN 镜像、开源项目仓库等第三方地址时，更需严格锁定。它们不受你控制，随时可能变更或删除。
- 示例：
jsoncpp https://github.com/open-source/jsoncpp/trunk@v1.9.5（如果该镜像支持 tag 路径） - 若对方不提供稳定 tag，可先
svn checkout一次拿到确切 revision 号，再填入 externals - 定期审查 externals 列表，标记已归档或不再维护的外部 URL，及时替换或移除
不复杂但容易忽略——版本锁定不是设一次就完事，它需要写进规范、纳入 Code Review、并在每次依赖升级时重新确认和提交。
