VSCode的SCM面板仅允许一个SCM提供者主导，SVN与Git插件共存时因协议冲突导致面板失效；需通过启动路径、设置scm.defaultSourceControl为git并重启来强制Git主控。
VSCode 不支持 SVN 和 Git 插件在同一个工作区共存管理源码 —— 这不是配置问题，而是底层协议冲突导致的 SCM 面板逻辑失效。
为什么 SVN + Git 插件会让源代码管理面板“失灵”
VSCode 的源代码管理（SCM）面板只允许一个活动的源码控制系统提供者（SCM Provider）主导视图。当同时启用 svn 扩展（如 JohnstonCode.svn-scm）和 git 内置支持（或 GitLens 等增强插件）时：
- 两者都会注册自己的
scm.provider，但 VSCode 仅激活其中一个（通常是先启动/加载更快的那个） - 未被激活的 SCM 系统会“隐身”：文件资源管理器里可能仍显示修改图标，但 SCM 面板不列出变更、不响应右键操作、不显示冲突区域
- GitLens 的
GitLens: Toggle Line Blame或GitLens: Open File on Remote等命令可能报错Command 'gitlens.toggleLineBlame' not found，因为 GitLens 检测不到可用的 Git 仓库上下文 - 执行
git status正常，但 VSCode 不刷新“Merge Changes”节 —— 因为它根本没把 Git 当作当前 SCM
如何强制 VSCode 使用 Git（而非 SVN）作为 SCM 主控
关键不是禁用 SVN 插件，而是让 Git “抢到” SCM 控制权。实操步骤如下：
- 关闭所有 VSCode 窗口，确保无缓存残留
- 打开终端，进入你的 Git 项目根目录（必须含
.git文件夹），再从该路径下运行：code . - 不要通过“文件 > 打开文件夹”方式打开项目 —— 这种方式可能触发工作区级 SCM 探测逻辑混乱
- 启动后立即按
Ctrl+Shift+P，运行Git: Refresh，观察 SCM 面板是否出现“Changes”“Staged Changes”等 Git 标准分组 - 如果仍显示 SVN 视图，打开设置（
Ctrl+,），搜索scm.defaultSourceControl，将其值设为git - 重启窗口（
Developer: Reload Window），此时 SVN 插件退为后台服务，仅保留右键菜单中的SVN: Commit等孤立命令，不再干扰 SCM 面板
需要 SVN 功能时的临时切换方案
你无法让两个 SCM 同时驱动 SCM 面板，但可以按需切换上下文：
- 对纯 SVN 项目：单独开一个 VSCode 窗口，且确保该窗口**不包含任何 .git 目录**（哪怕父目录有也不行）
- 对混合项目（例如主仓库是 Git，但子模块是 SVN）：避免在根目录打开；改用“文件 > 打开文件夹”单独打开 SVN 子模块路径，并禁用 GitLens 和其他 Git 扩展
- 快速执行 SVN 命令：按
Ctrl+Shift+P输入svn，可调出SVN: Commit、SVN: Update等命令，这些不依赖 SCM 面板，可独立运行 - 不要试图用
svn扩展去管理 Git 仓库里的.svn文件 —— 它们本就不该共存；若误检，检查工作区是否残留旧 SVN 元数据（如根目录下意外存在的.svn文件夹）
真正棘手的从来不是按钮点不点得亮，而是 VSCode 在启动瞬间就决定了谁掌控 SCM 面板 —— 这个决策不可 runtime 覆盖，只能靠启动路径和工作区结构来引导。多一个 .git，少一个 .svn，差的就是整个面板的响应能力。
