VS Code 的 SCM Providers API 允许扩展集成 Git 之外的版本控制系统，通过创建唯一 sourceControl 实例、提供资源状态、响应用户操作并驱动 UI 更新来实现并行 SCM 支持。
VS Code 的源代码管理提供程序（SCM Providers）API 让扩展能深度集成 Git 之外的版本控制系统，比如 Mercurial、Subversion、Perforce，甚至自定义的本地变更追踪系统。它不替换 Git 支持，而是并行提供另一套 SCM 视图、操作和状态更新机制。
SCM Provider 的核心职责
一个 SCM Provider 本质是告诉 VS Code：“我负责管理某类资源的变更”，然后通过几个关键接口暴露能力：
-
提供资源状态：哪些文件被修改、暂存、删除、冲突 —— 用
SourceControlResourceState描述，含图标、装饰标签、分组类型（如 “Changes”、“Staged Changes”） -
响应用户操作：点击“提交”“撤消更改”“暂存”等按钮时，触发对应命令（如
acceptInput、runCommand），由扩展自行实现逻辑 -
驱动 UI 更新：通过
sourceControl.statusBarCommands控制状态栏按钮，用sourceControl.count显示待提交数，靠resourceStates.replace(...)实时刷新文件列表
注册与初始化流程
在激活扩展时，调用 vscode.scm.createSourceControl(id, label, rootUri?) 创建实例。id 必须全局唯一（建议带命名空间，如 "my-svn.my-repo-123"），label 显示在源代码管理视图顶部，rootUri 指定作用范围（可为空，表示不限目录）。
接着需设置它的关键属性：
-
inputBox.value预填提交信息 -
quickDiffProvider（可选）支持内联差异对比（右键文件 → “Open Changes”） -
commitTemplate和acceptInputCommand协同控制提交流程
资源状态如何组织与渲染
VS Code 不要求你维护完整仓库状态，只需按需提供当前可见的资源快照。典型做法是：
- 监听工作区文件变化（
workspace.onDidChangeTextDocument等）或轮询后端服务 - 将变更映射为
SourceControlResourceState数组，每个对象指定resourceUri、command（右键菜单）、decorations（颜色/图标）、group（归属哪个资源组） - 调用
resourceStates.replace(states)批量更新 —— 这会自动触发 UI 重绘，无需手动 diff
例如，一个简单的“本地草稿追踪”Provider 可把未保存的编辑器标记为 SourceControlResourceStateGroup.Modified，点击即保存而非提交。
与 Git 扩展共存的注意事项
VS Code 允许多个 SCM Provider 同时激活。但用户只能看到一个“活动”的 SCM 视图（顶部下拉切换）。你的 Provider 不会干扰 Git 扩展，但要注意：
- 避免对同一文件路径重复声明变更（比如 Git 和你的 Provider 都报告 file.ts 已修改），会导致 UI 冗余或冲突
- 若想替代 Git 行为（如禁用 Git 扩展对某文件夹的扫描），需在
package.json中配置"contributes.scmProviders"并配合workspace.isTrusted或文件夹标识逻辑 - 状态栏只显示当前活动 SCM 的计数；其他 Provider 的
count仍有效，但不展示
基本上就这些。SCM Provider API 设计轻量，重点在“描述状态”和“响应动作”，而非封装底层协议。写得清楚，用户就能自然理解你的系统怎么工作。
