Composer 不支持 SVN 仓库，因其未注册 svn 类型且缺乏 VcsDriver 实现；唯一稳定方案是用 package 类型手动导出 ZIP 归档并配置 dist URL。
Composer 本身不支持直接配置 SVN 仓库作为包源——它原生只识别 git、hg（Mercurial）和 package 类型仓库，svn 不在官方支持列表中。试图在 composer.json 中写 "type": "svn" 或用 svn:// URL 会导致 Invalid repository type 错误或静默失败。
为什么 Composer 不接受 svn:// 协议的仓库
Composer 的仓库解析逻辑硬编码了支持类型，svn 未被注册为合法 type；即使你手动指定 "url": "svn://..."，也会因缺少对应 VcsDriver 实现而抛出 InvalidArgumentException: Repository of type "vcs" has no VCS driver。
- Composer v2.x 完全移除了对 SVN 的实验性支持（v1.x 中曾有极简适配但早已弃用）
-
svn+ssh://、http://（带 SVN WebDAV）等协议均无法触发任何内置驱动 - 第三方插件如
hirak/prestissimo或composer/composer自身都不提供 SVN 扩展点
可行替代方案：用 package 类型 + 手动导出
若必须从 SVN 获取某 PHP 库（比如遗留内部组件），唯一稳定方式是绕过 VCS 集成，改用 "type": "package"，并预生成可安装的 ZIP 归档：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 在 SVN 仓库中 checkout 目标版本（如
svn co https://svn.example.com/libs/mylib/trunk mylib） - 确保该目录含有效
composer.json（至少含name和autoload） - 打包为 ZIP：
zip -r mylib-1.2.0.zip mylib/ - 在项目
composer.json的repositories中添加：
{
"type": "package",
"package": {
"name": "myorg/mylib",
"version": "1.2.0",
"dist": {
"url": "./mylib-1.2.0.zip",
"type": "zip"
},
"autoload": { "psr-4": { "MyOrg\": "src/" } }
}
}
然后运行 composer require myorg/mylib:1.2.0。
自动化脚本能缓解但不能消除维护成本
你可以写 shell 或 PHP 脚本自动拉取 SVN、校验、打包、更新 dist URL，但每次变更都需重新触发该流程——这本质上把 Composer 当作 ZIP 解压器用，丢失了版本切换、diff 比较、依赖图谱等核心能力。
- SVN 的分支/标签模型与 Composer 的语义化版本（
^1.2）无法对齐，require中写"myorg/mylib": "^1.2"会失败 - 若 SVN 仓库无标准
tags/结构，需人工映射版本号到 revision 或路径 -
composer update不会检查 SVN 远端变更，必须手动重跑脚本+composer update --lock
真正需要 SVN 集成的场景，说明技术栈尚未完成向 Git 迁移——这时候更值得投入的是推动仓库迁移，而非在 Composer 上打补丁。临时 workaround 可行，但长期维护成本远高于预期。
