这是典型的“本地新增+远程也新增同名文件”引发的树冲突，本质是文件存在性冲突而非内容冲突；需通过svn status识别!C或C+“local add, incoming add”提示，据实际需求选择Revert、Accept working version或先删服务器版再add本地版，并显式标记resolve后验证状态。

这是典型的“本地新增 + 远程也新增同名文件”引发的树冲突，不是内容冲突，不会出现 <<<<< .mine 标记，而是 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 中维护一份“已存在清单”