这是树冲突，需先用svn status检查带!c或c标记的文件，如!c config/db.properties表示本地未版本控制文件与服务器已提交文件同名，c标记加“local add, incoming add”说明双方都新增了同一文件。

这类冲突不是代码改得不一样，而是“两边都新建了同一个文件”——SVN根本分不清该留谁的，所以直接卡住，属于树冲突（tree conflict），比普通内容冲突更底层、也更易被误判。

先确认是不是树冲突

别急着删或覆盖，先运行：
svn status
重点看有没有带感叹号的 !C 或纯 C 标记，比如：

• !C config/db.properties → 表示本地有未版本控制的同名文件，服务器上也有这个已提交文件
• C config/db.properties + 日志里出现 local add, incoming add → 说明你已执行过 svn add，但还没 commit，而别人抢先提交了同名文件

只要看到这些，就不是

按场景选处理动作

核心就看三点：文件谁先存在？内容要不要保留？权限是否允许操作服务器版本？

SVN搭建及使用教学视频(布尔教育)

《SVN视频教程》，SVN:全称Subversion，是代码版本管理软件，管理着随时间改变的数据。这些数据放置在一个中央资料档案库 (repository) 中。这个档案库很像一个普通的文件服务器,不过它会记住每一次文件的变动。这样你就可以把档案恢复到旧的版本, 或是浏览文件的变动历史。许多人会把版本控制系統想像成某种“时光机器”。

下载

• 本地文件还没 svn add，且服务器版本是正式配置 → 直接放弃本地版：右键文件 → TortoiseSVN → Revert，再 svn update 拉取服务器版
• 你已 svn add 但没 commit，服务器也有同名文件 → SVN 会拒绝你后续提交。选右键 → Resolve… → Accept incoming version，或手动删掉本地文件后 update 重拉
• 确定本地内容不可替代（如新模块的初始化脚本），且服务器版本可移除 → 必须先和团队同步确认；确认后，用 svn delete 删掉服务器版（需写权限），再 svn add 本地文件，最后 commit

怎么避免再踩坑

树冲突本质是协作节奏断层，预防比解决更重要：

• 新建任何文件前，先 svn update 刷新目录，看看有没有同名文件已存在
• 团队约定命名规则，比如配置文件统一加环境后缀：app-config-dev.yml、app-config-prod.yml
• 对高频新增类文件（如 SQL 脚本、测试数据模板），在项目根目录维护一个 NEW_FILES.md 清单，提交前先查一遍

不复杂但容易忽略，关键在动手前多看一眼状态，而不是凭感觉直接 add 或 edit。