这是典型的“本地新增+远程也新增同名文件”引发的树冲突，本质是文件存在性冲突而非内容冲突；需通过svn status识别!c或c+“local add, incoming add”提示，据实际需求选择revert、accept working version或先删服务器版再add本地版，并显式标记resolve后验证状态。
这是典型的“本地新增 + 远程也新增同名文件”引发的树冲突，不是内容冲突，不会出现 标记，而是 SVN 在文件系统层级发现两个来源都试图创建同一路径，无法自动裁决该留哪一版。
确认是“节点已存在”型树冲突
执行 svn status，重点看这类输出：
-
!C src/config.properties（感叹号+C，表示路径存在但未受版本控制，且有树冲突） -
C src/config.properties配合更新日志中提示local add, incoming add
这说明：你本地新建了 config.properties（可能已 svn add 但未提交），而服务器上也已有同名文件（他人早先提交）。SVN 把它识别为“两边都新增”，归类为树冲突。
按实际需要选择处理方式
核心判断依据：这个文件到底该用谁的？是否已有权威版本？
-
服务器版本是正式配置，你本地的是临时草稿：右键文件 → TortoiseSVN → Revert（撤销本地新增），再执行
svn update即可拉取服务器版 -
你本地的内容必须保留，服务器版可废弃（如误提交的模板）：先联系团队确认；然后
svn delete服务器版本（需权限），svn add本地文件，最后svn commit - 两边内容都要，需合并逻辑：手动打开两个文件对比，把本地新增的关键配置项（如数据库地址、开关项）复制到服务器版中；保存后，右键 → TortoiseSVN → Resolve… → 选 Accept working version（即你编辑后的版本）
标记解决并验证
无论哪种操作，完成后必须显式标记冲突已处理：
- 命令行：
svn resolve --accept working src/config.properties - TortoiseSVN：右键文件 → Resolve… → 勾选 Mark resolved
再运行 svn status，确认该文件不再显示 C 或 !C，而是变为 A（新增）、M（修改）或空白（已同步），才算真正解决。
预防下次再出现
这类冲突本质是协作节奏不同步，关键在“动手前多看一眼”：
- 新建配置文件、SQL脚本、文档等之前，先
svn update并svn list目录，确认无同名项 - 团队约定命名规则，比如区分环境：
app-dev.yml、app-prod.yml，避免都叫app.yml - 对高频新增类文件（如日志模板、接口定义），在项目根目录
README.md中维护一份“已存在清单”
