如何使用SVN解决工作副本中代码文件状态冲突实用指南

SVN代码冲突这件事，很多刚接触版本控制的朋友一看到“Conflict”这个单词就慌了，觉得是不是自己操作出了问题。其实大可不必紧张——它只是协作过程中一个再正常不过的信号，提醒你：本地修改和服务器上别人提交的最新版本，在同一个文件、同一个位置发生了“意见分歧”。真正重要的不是“如何完全避免冲突”，而是当它来临时，能快速认清形势、理清各方意图、安全地把代码合并回去。

看清冲突状态与临时文件

当执行一次 svn update，系统直接弹出一行“Conflict discovered in…”的提示，那就说明，冲突已经发生了。接下来第一件事，不是急着打开文件改代码，而是先看清战况：

• 运行 svn status，那些被标记为 C（Conflict）的文件，就是你要处理的目标。
• 与此同时，目录里会多出三个临时文件：.mine（你改的版本）、.rOLDREV（更新之前的服务器版本）、.rNEWREV（别人刚提交的新版本）。
• 注意，这三个文件只是用于参考对比的，SVN在冲突解决后通常会自动清理它们，不用自己手动保留。

读懂冲突标记再动手编辑

打开那个标记着C状态的文件，你会看到代码中插入了类似这样的分隔符结构：

• 从 <<<<<< .mine 到 ======= 之间，是你自己改的那部分；
• 从 ======= 到 >>>>>> .r123 之间，是别人提交的改动。

那什么是关键？不是只看标记符号，而是要看它背后的逻辑。举个例子：对方改了一个参数名，那你需要判断它是否影响了你这边对它的调用；对方新增了一段校验逻辑，你要考虑它是否和你的修改兼容；如果日志格式不一样，也需要统一处理。别急着把它们全删了，先理解再动手。

手动合并后必须显式标记解决

很多人以为只要把文件编辑好、保存了，冲突就算处理完了。不对，SVN还在等着你给它一个明确的信号：告诉我，你已经确认完毕。这步不能跳：

• 最稳妥的做法：执行 svn resolve --accept working 文件名。这条命令的意思是“我用我手工编辑后的版本作为最终内容”。推荐优先使用。
• 不推荐直接 --accept mine-full 或 --accept theirs-full——它们会简单粗暴地覆盖掉另一方的修改，等于无视了协作中本应整合的价值。
• 标记成功后，再运行 svn status，那个文件的冲突状态应该变成了一个空格（正常）或者 M（已修改）。

提交前务必验证与清理

信号发送完了，这篇文章就到了最后一步。但别急着直接提交：

• 先用 svn diff 文件名 快速扫一遍最终内容，确认你要提交的代码确实没问题。
• 检查一下有没有 .mine 或 .r* 这样的临时文件被意外混入待提交列表——它们不是源码，不需要进仓库。
• 最后执行 svn commit -m "修复 UserService.login 冲突：整合密码校验与参数规范"。提交信息不只是一个形式，它写清楚“为什么要合并”才是关键，如果只写“fix conflict”，等于什么都没说。