VSCode SVN插件需手动配置svn.path指向本地svn可执行文件，且必须打开含.svn目录的根文件夹才能激活功能；版本不兼容、路径错误或工作副本过旧均会导致插件失能。
VSCode 本身不带 SVN，插件只是个“遥控器”，真正干活的是你本地装的 svn 命令 —— 配不对其路径，插件就彻底失能，连状态栏都不显示分支名。
怎么确认 VSCode 能调到正确的 svn 可执行文件
插件不会自动 fallback 到 PATH，也不会猜你装在哪。它要么从设置里读 svn.path，要么（极少数情况）依赖启动时继承的 shell 环境变量。
- 先在终端跑
svn --version，确认输出是1.6.x、1.7.x或1.8.x（老项目大概率卡在这几个版本）；如果输出1.14.0或更高，基本没法连旧服务端 - Windows 上 TortoiseSVN 默认不加
svn.exe到 PATH，得手动去C:Program FilesTortoiseSVNinsvn.exe找，或重装时勾选 “Command line client tools” - macOS/Linux 若用 Homebrew 装了新 svn，但项目要 1.8，就得单独下 SlikSVN 1.8 并指定路径，比如
/usr/local/svn18/bin/svn - VSCode 设置里搜
svn.path，填绝对路径（Windows 注意反斜杠写成双\或全用/），填完必须重启 VSCode —— 缓存不刷新，旧路径还在用
为什么打开项目后 SVN 图标不出现、右键没菜单
这不是插件坏了，是 VSCode 根本没识别出这是个 SVN 工作副本。它只认一种结构：当前打开的文件夹里，必须有 .svn 这个目录，且是顶层根目录。
- 常见错误：用
svn checkout https://xxx/trunk myproj拉下来，却在 VSCode 里打开的是myproj/src——.svn在myproj下，src里没有，插件直接静默 - 验证方法：在资源管理器顶部看有没有 “SOURCE CONTROL” 面板，并显示 “SVN” 字样；或者按
Ctrl+Shift+P输入SVN: Show Log，能弹出日志才说明识别成功 -
.svn是隐藏目录，Windows 资源管理器默认不显示，得手动开启 “显示隐藏的项目”；误删会导致整个工作副本失效 - 别把 SVN 项目放在 Git 仓库子目录里（比如
git-repo/svn-subproject），GitLens 和 svn-scm 会互相干扰，状态栏可能显示 Git 分支，SVN 功能全灰掉
提交失败、更新卡住、提示 “Working copy is too old” 怎么办
这些不是配置问题，是 SVN 客户端和服务端/工作副本格式不兼容的典型症状。VSCode 插件只负责调命令，底层逻辑还是原生 svn。
- 报
E155036: Working copy is too old：说明工作副本是高版本客户端（如 1.14）创建的，而你配的是 SlikSVN 1.8 —— 解决办法只有进终端，cd 到项目根目录，运行svn upgrade（前提是该客户端支持升级） - 提交前务必点左下角状态栏 SVN 分支名 → “Update”，或手动执行
SVN: Update；跳过这步直接提交，服务器会因版本过期拒绝，且可能覆盖他人修改 - 遇到
RA layer request failed或SSL handshake failed：老 SVN 服务端常只支持 TLS 1.0/1.1，SlikSVN 1.8 可设环境变量SSLVersion=TLSv1，或改用http://协议（如果服务端允许） - 首次检出别用 VSCode 右键 “SVN > Checkout”，容易卡死；先终端跑
svn checkout <url> ./project，再用 VSCode 打开project文件夹
最易被忽略的一点：VSCode 插件完全不读取系统 ~/.subversion/server 配置，代理、证书忽略、自定义 CA 这些都得先在终端用 svn info 验证通了，插件才能跟着跑通。否则它会在后台静默失败，你只看到“没反应”。
