svn代码冲突是协作中自然发生的信号，需快速识别（svn status查c状态）、理解三方版本（.mine/.roldrev/.rnewrev）、手动融合逻辑、用svn resolve --accept working显式标记解决，再验证提交。
SVN 代码文件冲突不是“出错了”，而是协作中自然发生的信号——它提醒你：本地修改和服务器最新版在同一个位置产生了分歧。关键不在于避免冲突，而在于快速识别、理解意图、安全合并。
看清冲突状态与临时文件
执行 svn update 后若出现 “Conflict discovered in…” 提示，说明已触发文本冲突。立刻运行：
- svn status —— 查看哪些文件标记为 C（Conflict），这是最直接的入口
- 留意同名生成的三个辅助文件：.mine（你改的）、.rOLDREV（更新前服务端版本）、.rNEWREV（别人刚提交的新版）
- 这些临时文件只是参考，解决后 SVN 通常会自动清理，无需手动保留
读懂冲突标记再动手编辑
打开带 C 状态的文件，你会看到类似结构：
和 <code>=======之间：你的本地修改-
=======和>>>>>> .r123之间：别人提交的改动 - 不要只删标记、不看逻辑；重点判断：参数重命名是否影响调用？新增校验是否该保留？日志格式要不要统一？
手动合并后必须显式标记解决
保存编辑后的文件只是第一步，SVN 仍认为它处于冲突状态。必须执行明确指令告知系统：“我已处理完毕”：
- svn resolve --accept working 文件名 —— 最推荐，表示你已手工融合并确认最终内容
- 慎用
--accept mine-full或--accept theirs-full，它们会直接覆盖另一方修改，丢失协作价值 - 标记完成后，svn status 中该文件状态应变为 （空格，即正常）或 M（已修改）
提交前务必验证与清理
标记解决不等于完成闭环：
- 先用 svn diff 文件名 快速核对最终提交内容是否符合预期
- 确保没有残留的
.mine/.r*文件被意外加入提交（它们不是源码，也不该进仓库） - 最后执行 svn commit -m "修复 UserService.login 冲突：整合密码校验与参数规范"，提交信息写清合并意图
