刘寅生律师1. 从一次线上事故说起：合并冲突不是“点一下”的事
大概每个用过SVN的开发者，都经历过那个让人血压升高的瞬间：本地代码写得好好的，svn update一敲，屏幕上冒出一行红色的C，旁边跟着一个文件名。用 TortoiseSVN 的朋友更直接，右键菜单里弹出一堆英文选项：Edit Conflicts、Accept mine、Accept theirs、Accept merged。新手通常一脸懵，老手也未必每次都能选对。
这个“弹窗瞬间”看起来只是让你做一道四选一的选择题，但选错之后的连锁反应，往往要到几小时甚至几天后才显现。我印象很深的一次线上事故，同事在一份公共配置文件的冲突弹窗里，随手选了“Accept theirs”，结果把自己改了半天的支付回调配置全部覆盖掉了，测试环境直接崩了。还有一次，另一个同事在svn merge合入分支代码时选了“Accept mine”，分支上别人写的新接口一个都没合进来，提交之后还沾沾自喜说“冲突都解决了”，最后整个功能模块在主干上根本跑不起来。
这些场景你有没有觉得特别熟悉？其实合并冲突本身不可怕，SVN 的冲突处理机制也远没有传说中那么难用，真正可怕的是很多人根本没搞懂那几个选项背后的含义，就凭直觉提交了事。
今天这篇文章，我想完整地梳理一遍SVN合并冲突的底层逻辑、五个可选项的真实含义、不同场景下的正确选择，以及我自己踩过无数坑之后总结出来的决策指南和命令行技巧。无论你用的是 TortoiseSVN、IDEA内置SVN，还是直接用命令行，这篇文章都值得你花十分钟读完。读完你会知道，冲突弹窗出现的那一刻，你到底应该怎么选，以及为什么这么选。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 冲突产生的底层机制：为什么SVN会“卡住”不动
2.1 SVN合并的三方对比逻辑
要搞懂怎么选，先搞清楚SVN在合并时到底在做什么。很多人的误区是：SVN会自己把两份代码“智能合并”，只有当它实在搞不定时才弹窗问你。这个理解对了一半。
SVN版本管理的核心模型是base + working + target三方对比。拿最常见的svn update来说，当你执行更新命令时，工作副本里有三个角色的文件同时在场：
base：你上次更新/提交时的原始版本（共同祖先）working：你本地当前修改后的版本target：仓库里其他人提交的最新版本
SVN会先把base与working做一次diff，找出你改了哪些；再把base与target做一次diff，找出别人改了哪些。如果两边改的是文件中完全不同的行，SVN能自动合并，你甚至感觉不到发生了什么。但如果两边都改了同一行，或者你改了某一行而别人把这一行所在的整个函数重写了，这两份diff就“撞车”了，SVN无法替你判断谁对谁错，于是生成一个冲突标记，把文件标记为冲突状态。
想理解这个机制，可以想象三个人合写一份合同：张三（base）起草了初稿，李四（working）在手写的复印件上改了第二条，王五（target）在另一份打印件上也改了第二条，但两个人改的内容完全不一样。此时李四和王五各持一份，“哪个才是最终版本”不是复印机能自动判断的，必须由人来拍板。SVN的冲突弹窗，本质上就是那个“最终拍板”的对话框。
2.2 更新冲突与合并冲突是两条不同路径
这里必须区分一个经常被混淆的点：svn update（更新）时出现的冲突，和svn merge（合并）时出现的冲突，虽然弹窗界面上看起来差不多，但语义上有一条非常微妙的差异。
svn update是把远端仓库的最新版本“拉”到本地，你的本地修改保留，目标版本是远端代码。此时冲突的本质是“我要保留我的修改，还是接受别人的修改”。svn merge则是把你所在分支（比如feature分支）的提交记录“合并”到另一个分支（比如主干）上，整个合并本身就是一次修改操作。此时冲突的本质是“合并过来的代码与目标分支的代码，哪一处才是这两条分支应该保留的正确版本”。
两条路径下，同样写着“Accept theirs”的选项，实际代表的内容可能完全不一样。这也是很多人乱选一通之后、代码变得一团糟的核心原因。
提示：不要以为“更新冲突”和“合并冲突”是同一个东西。在继续往下读之前，先想清楚你当前到底是在执行
update还是在执行merge，这决定了后面每个选项的真实含义。
3. 右键弹窗里的五个选项，到底各自代表什么
3.1 从TortoiseSVN到命令行：统一理解五个词
TortoiseSVN的冲突弹窗里，通常会出现这几个选项，对应的英文分别是Accept mine、Accept theirs、Accept merged、Edit Conflicts，有的版本还有Mark as resolved。IDEA的SVN集成界面里，对应的是Accept Yours、Accept Theirs、Merge。命令行里，--accept参数的取值是working、theirs-conflict、theirs-full、mine-conflict、mine-full。术语虽然五花八门，但指向的其实是同一套底层语义。
我先把五个核心词的核心含义表格化，后面再逐个拆解适用场景。请注意，这里的“我/你”指的是本地工作副本，“对方”指的是冲突的另一方。
| 选项名称（以TortoiseSVN为准） | 实际含义 | 文件最终内容 |
|---|---|---|
| Accept mine | 保留本地修改，丢弃对方修改 | 完全是你本地的最新内容 |
| Accept theirs | 采用对方修改，丢弃本地修改 | 完全是对方（更新目标/合并来源）的内容 |
| Accept merged | 接受手动编辑后的结果 | 你自己手动解决后的内容 |
| Edit Conflicts | 打开编辑器手动解决冲突 | 你逐行编辑后的内容 |
| Mark as resolved | 标记为已解决（需要在文件确实没问题后才点） | 保持当前工作副本内容 |
这里有个非常容易踩坑的细节：Accept mine在TortoiseSVN里的英文原文是Accept mine (mine full)，命令行参数是--accept mine-full。它表示整个文件都用本地版本，完全忽略对方。同理，Accept theirs是theirs-full，整个文件都用对方版本。而IDEA里的Accept Yours对应的其实也是mine-full，不是“只保留你冲突的那几行”，这个理解错误极其常见。
3.2 为什么“mine”和“theirs”在不同场景下含义会翻转
这里必须画一个重点：mine和theirs的相对关系，会随着你是执行update还是merge而翻转。这可能是SVN最反直觉的地方。
当你在自己的分支上开发，执行svn update更新主干其他人提交的代码时，mine是“你本地的修改”，theirs是“从主干拉下来的别人代码”。此时两个词的含义跟直觉一致。但当你执行svn merge把另一个分支合并到当前分支时，mine是“当前分支（目标分支）的现有内容”，theirs是“被合并分支带来的内容”。假如你在合并时选了Accept theirs，你并不一定是“接受了别人的修改”——你可能是“把被合并分支的内容整体覆盖到当前分支”。
举个例子：你在trunk上执行svn merge ^/branches/feature，某个文件在trunk上的版本是A，在feature上的版本是B，两者冲突。弹窗里的Accept theirs会把文件变为B，也就是“让feature的内容覆盖trunk”。如果你业务上期望保留trunk的A版本内容，你应该选Accept mine，而不是Accept theirs。这个概念的混淆，是团队日常开发中引发最多“代码神秘消失”问题的根源。
注意：我先给出一个傻瓜式的总原则——不确定的时候，永远优先打开文件手动编辑冲突，而不是盲选mine或theirs。后面我会详细说明手动处理的完整流程，以及哪些情况可以放心选“整文件覆盖”。
4. 更新场景实战：svn update 冲突后五个选项怎么选
4.1 逐项拆解：更新冲突时每个选项的真实后果
我们先看最常见的场景：你正在改代码，svn update之后，某个文件标红了。这个文件的本地版本里有你加了半天的日志模块，而后端同事在同一文件里改了配置项和接口定义，SVN无法自动合并。
此时，弹窗里每个选项点击后的实际后果是这样的：
Accept mine（保留我的）：整个文件回退为你本地版本，后端同事针对这个文件的所有修改都会被丢弃。如果你后续直接svn commit，你等于用自己本地的旧版本覆盖了刚更新的远端版本。如果这个文件里包含别人刚加的接口常量、配置文件里新加的开关，这些都会“被消失”。
Accept theirs（保留对方的）：整个文件回退为远端最新版本，你本地所有未提交的修改全部被丢弃。如果你的修改存在且没有被备份，点击之后基本找不回来了（在不少版本里可以从.svn的临时文件翻出来，但绝大多数人不知道这一点）。
Accept merged（接受合并结果）：这一步其实需要你手动编辑过冲突区块之后才有意义。如果你没编辑过就点它，工作副本仍然会处于冲突标记状态，提交会被拦下来。
Edit Conflicts（编辑冲突）：打开编辑界面，此时编辑窗口里会出现<<<<<<< .working、=======、>>>>>>> .merged这种标记，你需要逐行决定保留哪边、删掉哪边，保存后再点Mark as resolved。
Mark as resolved（标记已解决）：直接当前的working内容标记为最终状态，不强制做任何检查。这个操作的实际效果约等于“告诉SVN你别管了，我自己搞定”，哪怕文件里还残留着冲突标记，它也会被提交上去。
4.2 更新冲突时最稳妥的三个判断法
现在问题来了：真正遇到更新冲突时，我到底该怎么选？
我给出的实战建议是：先分层判断，再决定选项。
第一层判断：这个文件的冲突范围大不大？如果只是某个配置项两个人改成了不同值，文件里其他内容都没动过，那你可以打开Edit Conflicts手动选中你要的那个值，保存后标记已解决，这种做法最精确。
第二层判断：如果冲突范围很大，你已经记不清本地到底改了什么，我强烈建议你打开Edit Conflicts，先看一眼本地修改和远端修改的差异。注意，这一步其实SVN提供了一个非常有用的预览——冲突窗口上方会显示两栏或三栏对比，你能直观看到哪几行是working的，哪几行是theirs的。
第三层判断：如果当前冲突的整个文件就是某个人的独立模块，几乎没有重叠，我才会考虑直接选Accept theirs或Accept mine。比如后端同事重写了整个接口文件，你只是在这个文件里改了一行注释，那完全可以直接选Accept theirs，然后把你的一行注释重新加上去。
我还要在这里提醒一个特别容易忽略的点：更新冲突里选Accept theirs之前，务必先把本地版本复制一份出来。你可以把冲突文件复制成一个.bak文件放在同目录下，解决完冲突确认无误后再删掉。这个习惯一开始会有点繁琐，但真能救回你几个小时的工作量。
4.3 IDEA里的SVN冲突界面怎么看
如果你用的是IDEA的SVN集成（IDEA Settings → Version Control → Subversion），冲突弹窗略有不同，但底层逻辑一模一样。IDEA的冲突解决对话框里，左边是你本地版本（Yours），右边是服务器版本（Theirs），中间是合并结果。你可以在左右两边分别选择“采用哪一行”，也可以直接在中间结果里编辑。
IDEA有一个非常实用的功能：每个冲突区块单独处理之后，可以只保留某些区块的本地内容，某些区块用远端内容。这比TortoiseSVN那种整个文件二选一的默认操作更精细。所以如果你在IDEA里做SVN，正确的解决姿态通常是：不要点那个大按钮“Accept Yours”或“Accept Theirs”，而是逐块用鼠标点选中间结果区，一块一块确认。逐块确认虽然慢一点，但每一条冲突都不会被冲掉，这才是真正的“只解决冲突的那一段，其他的正常合并”。
上面这句话其实说到了很多人的痛处。热词列表里有一条就是“idea 代码冲突如何只解决冲突的那一段，其他的正常合并”，这个问题准确的答案就是：在IDEA冲突对话框里逐个点击冲突块，选中想要的内容，不要使用整个文件的Accept按钮。如果你用的是TortoiseSVN，等价做法是在Edit Conflicts打开之后，对每个冲突区块执行Use text from "theirs"或Use text from "mine"。
5. 合并场景详解：svn merge 遇到冲突时的选项与陷阱
5.1 合并冲突的独特性：合并方向决定“my”和“theirs”
合并冲突的处理比更新冲突更容易踩坑，因为牵扯到“合并方向”这个概念。
假设你要把branches/feature-x合并到trunk。在trunk上执行：
code复制svn merge ^/branches/feature-x
如果在某个文件上发生了冲突，那么弹出的Accept theirs，指的是feature-x分支上的内容；Accept mine，指的是当前trunk上的内容。这个规则看起来清晰，但真实团队里经常出现这样的场景：某人从trunk拉了分支feature-x，在分支上改了很多东西；后来trunk上其他人也改了同一处代码；再后来feature-x准备合回trunk，于是冲突出现了。
在这种场景下，两个分支上的代码都是“自己人”写的，mine和theirs哪边才是最终想要的，完全取决于业务决策，技术上没有标准答案。我个人遇到这种场景时的习惯是：在合并前先给两条分支各自打个分支标签或者做个记录，合并时用TortoiseSVN的查看日志功能对比两个分支上这个文件各自的历史提交，搞清楚两边各自改了哪些点，然后再决定是逐块合并还是整边覆盖。
另一个常见陷阱是svn merge --reintegrate。老版本SVN中，--reintegrate用于把分支“回融”到主干，它把合并时的差异处理逻辑变得更严格。在Reintegrate合并里，如果出现冲突，选项的含义依然是“mine=目标分支现有内容，theirs=来源分支内容”，但很多人会把“回融”误以为“应该完全接受来源分支的内容”，结果直接Accept theirs，导致trunk上已有的、但feature分支上没有的修改全部被覆盖。这类操作属于合并事故的高发区，一定要谨慎。
5.2 用命令行解决合并冲突：一个完整可抄的流程
如果团队里习惯用命令行操作SVN，冲突解决其实比鼠标右键更可控。下面是一套完整的命令行冲突解决流程，我贴出来供你直接使用。
假设我的本地分支是trunk，远端分支是branches/feature-x，我先执行：
bash复制# 切到目标分支（trunk）
svn switch ^/trunk
# 拉取最新代码
svn update
# 把feature-x合并到当前分支
svn merge ^/branches/feature-x
此时如果出现冲突，svn status会显示冲突文件的状态。然后我用：
bash复制# 查看冲突文件的详细状态
svn status
输出中文件名前出现C的就是冲突文件。接着逐个文件处理：
bash复制# 方式一：整文件保留当前trunk版本（mine-full）
svn resolve --accept working 文件名
# 方式二：整文件保留feature-x版本（theirs-full）
svn resolve --accept theirs-full 文件名
# 方式三：只保留冲突区块的本地/远端内容
# 先手动编辑文件，把冲突标记解决干净
# 编辑完成、去掉所有<<<<<<< ======= >>>>>>>标记后，再执行：
svn resolve --accept working 文件名
命令行里有一个容易搞混的参数：--accept working和--accept mine-full。很多人以为两者等价，但实际上在svn resolve的语境下，working表示“保留当前工作副本里手动编辑解决后的文件”，而mine-full在某些旧版本里表示“整体使用合并前本地基础版本”。虽然多数场景结果一样，但在部分SVN版本中行为有微妙差别。我非常推荐的做法是：手动编辑完冲突文件之后，统一用svn resolve --accept working标记解决，这既是标准姿势，也最不容易被版本差异坑到。
5.3 大范围冲突时，更建议用补丁式合入
如果你的合并场景是两条分支改动非常大，整个文件几乎每一个区块都在冲突，逐行编辑会让人崩溃。这时候我的经验是：放弃直接svn merge后的冲突解决，改用补丁式合入。具体操作：先让冲突文件保持原样，把当前合并操作svn revert掉，然后在冲突文件上单独用文本对比工具（比如 Beyond Compare、WinMerge）手动对比两个版本，把要的差异挑出来，手工粘贴到目标文件里，最后再提交。
为什么推荐这种做法？因为在大量冲突的场景下，SVN生成的冲突标记会让文件变得极其难读，稍不留神就会在删掉标记的时候误删代码。用外部对比工具反而能给你更清晰的双栏或者说四栏视图。而且外部工具能帮你精确控制哪些行留下、哪些行丢弃，完全符合“只解决冲突的那一段，其他正常合并”的需求。
补丁式合入的操作流程是：
- 先撤销当前的合并冲突状态：
svn revert 冲突文件，让文件回到合并前的trunk版本。 - 从分支上导出最新的对应文件副本：
svn export ^/branches/feature-x/conflict_file ./feature_conflict_file - 打开一个双栏对比工具，左边是trunk当前版本，右边是feature-x的副本。
- 人工把右边要合并的代码粘贴到左边，保存。
- 在trunk上执行
svn add或svn commit提交。
这个流程比直接处理冲突标记更费时，但在分支偏离了很久、改动量很大的情况下，反而更安全更省心。记住：解决冲突的目的不是“消掉红色标记”，而是“生成一份所有人都认可的正确代码”。
6. 最危险的几个操作：这些坑我全都踩过
6.1 不要用“Accept mine”当偷懒工具
我见过太多开发人员在遇到冲突时，不管三七二十一直接Accept mine，理由是“我本地的是最新的”。这个逻辑在多数轻量冲突场景下并不成立。你本地的新，可能只是在自己的一亩三分地里新；别人在同一个文件里新加的接口定义、新配置的依赖版本、新修改的工具类方法，极可能是你完全没看到过的重要内容。
举个例子：一个团队在constant.js文件里维护所有状态码。你本地加了一个STATUS_ORDER_CLOSED = 5，另一个同事加了STATUS_REFUNDING = 6，两个人的修改都在文件末尾新增了一行。按理说这是能自动合并的，但如果你们两个人同时改了文件末尾的同一个位置，SVN就只能把它标为冲突。此时你选Accept mine，同事的STATUS_REFUNDING = 6就丢了，线上代码一旦用到这个状态码，直接undefined，事故级别的事。为了省30秒的编辑时间，埋下一个几小时的排查隐患，真不划算。
我的建议是：任何包含常量、配置、接口定义、依赖版本的文件，遇到冲突一律逐行手动解决。这些文件的价值密度极高，丢一行都可能在运行时炸出诡异问题。
6.2 不要忽略.mine和.rNEW文件
在TortoiseSVN里，当你手动编辑冲突文件时，工作目录通常会出现几个隐藏的临时文件，命名规则大致是文件名.mine、文件名.r1234、文件名.r5678。其中.mine是冲突时你的本地完整版本，.r1234等是冲突时对方的基础版本和其他版本。
这几个文件常常被视作垃圾文件，但关键时候它们就是救命稻草。尤其是当你误点了Accept theirs或Accept mine之后，发现代码丢了，只要工作副本里这些临时文件还在，你还有机会把丢掉的内容捞回来。
我之前有一个同事，误选了Accept theirs后，整个本地文件被覆盖，他当时在冲突文件里改了大半天的新功能全部消失。我们后来就是靠.mine临时文件把本地方案copy出来，再手动合并回去的。所以，在确认冲突解决正确之前，不要急着清理这些临时文件。
6.3 千万别提交带有冲突标记的文件
这个属于每个人都知道、但总有人犯的低级错误。文件里只要还残留着<<<<<<<、=======、>>>>>>>这些标记，在多数IDE和构建工具里其实并不会立刻报错，所以代码依然能编译、能跑。于是有人直接svn commit，把这种带标记的文件提交上去了。等到其他同事更新代码，或者CI构建上线，才发现某个文件在语法上是对的、逻辑上却完全错乱。
如果遇到这种情况，解决方案是：在提交之前强制执行一次搜索，全局搜索<<<<<<<和>>>>>>>，确保没有任何一处冲突标记被遗漏。我自己的习惯是：提交SVN前必跑一次全局搜索，页面文件、配置文件、代码文件全部查一遍，看到类似标记就停下来处理干净。这个习惯帮团队拦下了好几次事故。
6.4 关于Clean up的一则提醒
热词里有“svn怎么没有clean up”这种问题，这也和冲突处理相关。当你在解决冲突过程中误操作、或者程序崩溃，工作副本有时会进入一种被锁定的状态，右键菜单里的Clean up变成灰色不可点，此时你无法继续更新或提交。早期SVN版本会非常头疼，新版本（1.7及以上）的Clean up通常能解决大部分锁定问题。如果你在使用1.6这种老版本，清理锁定需要手动删.svn目录里的lock或wc.db相关临时文件，操作不当可能损坏工作副本。我的建议是：工作中尽量升级到较高版本的SVN客户端和服务器，既能少很多坑，也能兼容更多的合并特性。
7. 冲突解决工具的选型与配置：人靠衣装、马靠鞍
7.1 TortoiseSVN 的“Edit Conflicts”怎么配才高效
提到SVN冲突解决，多数Windows用户会用到TortoiseSVN（俗称小乌龟）。很多人的工作流是：冲突弹窗里点Edit Conflicts，然后直接用默认文本编辑器打开冲突标记文件，手动删标记、剪贴代码。这个流程能做，但效率确实低。
更推荐的方式是把外部对比工具配置为TortoiseSVN的合并工具。打开TortoiseSVN的Settings → Diff/Merge，在Merge Tool区域选择你电脑上安装的Beyond Compare或WinMerge。配置完之后，遇到冲突直接点Edit Conflicts，它会自动调用外部工具，以左右并排的视图把冲突区域高亮出来，左边是本地版，右边是对方版，中间或者底部是合并输出区。在这种情况下，你可以逐块点击“使用左侧/使用右侧”按钮，最终生成一个干净的合并结果，保存后就地解决冲突。这套流程用起来比手撕<<<<<<<标记舒服得多。
7.2 命令行工具怎么配：别忽视SVN自身的编辑命令
如果团队环境是Linux开发机，没有图形界面，那你需要掌握命令行下的冲突编辑方式。当冲突产生时，直接打开冲突文件，文件里跟TortoiseSVN编辑出来的标记完全一样。
举个简单的编辑过程：
bash复制# 1. 查看冲突标记位置
grep -n "<<<<<<<" 文件名
# 2. 打开文件手动编辑
vim 文件名
# 3. 编辑完成后，找到冲突标记，按需删除
# 4. 结束编辑，确保文件里没有冲突标记
# 5. 标记为已解决
svn resolve --accept working 文件名
编辑过程中，你可能会看到类似这样的内容：
code复制<<<<<<< .working
int price = 100;
=======
int price = 200;
>>>>>>> .merged
这表示左侧（working）是100，右侧（merged）是200。你根据自己的业务需求，决定保留其中一个，然后删掉三行标记行即可。唯一要注意的是：如果两边代码块之间有重复的部分，不要机械地只保留一边，而是把两边都需要的合并到一块儿去。
7.3 服务端与客户端的版本搭配，也会影响冲突表现
很多团队对SVN版本升级不太上心，但版本落后确实会直接影响到冲突体验。比如老版本客户端在处理目录合并、树冲突时，经常出现难以处理的错误。新版本在树冲突（tree conflict）上的体验好了很多，能比较清晰地告诉你：这个本地新增文件被对方删除了，或者这个本地修改的目录被对方移动了，应该怎么处理。
- 树冲突的场景：本地把文件
util.js重命名为helper.js，别人在同一版本里也修改了util.js。 - 树冲突的处理方式：通常需要手动决定保留哪个文件、删除哪个文件，然后统一重命名。
这类问题在纯文本冲突解决的基础上多了一个文件级别判断，容易让人一时不知道从何入手。我的建议是：遇到树冲突不要慌，svn status会明确列出问题文件的类型，优先和冲突相关的同事沟通确认，然后手动完成文件保留、重命名、删减的操作。
8. 冲突解决防丢失三步法：一个老开发的专业建议
8.1 三步法总览
前面讲了大量理论，这里我要拿出压箱底的一套“冲突解决防丢失三步法”。这套方法适用于绝大多数更新、合并冲突场景，如果你暂时还没有更好的固定流程，可以直接按这套来。
第一步：先备份，再操作。遇到冲突，绝不直接点Accept mine或Accept theirs。先把冲突文件复制一份（或者索性把工作副本里所有冲突文件统一打包），命名成文件名_冲突备份_日期，放在工作副本外部的临时目录。这个动作可能只花10秒，但能挡住绝大多数误操作。
第二步：看差异，再动手。打开冲突编辑界面，逐块查看本地修改与远端修改的差异。这里的重点是：不要只看冲突标记附近的内容，而是从整个文件的角度去理解，为什么这一处会出现冲突？是两个人的改动重叠，还是远端把整个文件结构重构了？理解了之后，再做取舍。
第三步：验证后再提交。手动解决完冲突、标记为resolved之后，先本地编译/运行一遍，确认没有语法错误、功能影响，再执行svn commit。如果项目有自动化测试，跑一圈测试再提交更好。这个步骤能保证你解决冲突时引入的新问题不会直接推到主干上。
8.2 一个实战案例：配置文件的逐块合并
最后举一个完整的实战案例。假设我在application.properties里加了一个数据库连接池的配置项ds.maxPoolSize=50，同事在同一文件里把server.port=8080改成了server.port=9090，两个人还都改动了文件末尾的注释区，于是冲突出现。
我打开冲突文件的编辑界面，里面大概是：
code复制<<<<<<< .working
server.port=8080
ds.maxPoolSize=50
=======
server.port=9090
ds.maxPoolSize=100
>>>>>>> .merged
这个例子是我故意设计成“同一行附近有分歧”的典型情况。实际上SVN把整个区块标为冲突，因为两条修改都落在一个连续区域内。这种情况下，正确做法不是选择其中一方，而是手动合并成：
code复制server.port=9090
ds.maxPoolSize=50
也就是说，跑步端口采用同事的9090，连接池大小保留本地的50。如果你点Accept mine，端口变成了8080，跟同事的改动冲突；如果点Accept theirs，连接池变成了100，可能远超数据库实际承受能力。只有手动把两边的改动都合起来，才能得到“既保留自己配置、又不覆盖同事配置”的最终结果。这个场景是冲突逐块解决最好的样板。
我在实际工作中看到过太多次，因为图省事选了一个整文件选项，结果把别人的端口配置或自己的连接池配置覆盖掉，导致半天排查季。“只解决冲突的那一段，其他正常合并”绝不只是IDE里的一个按钮，而是一种解决问题的心态。
9. 写在最后：冲突不是负担，而是一次代码审查机会
我做了这么多年开发，SVN项目的经验告诉我，合并冲突处理得好不好，往往是一个团队工程素养的试金石。把每次冲突都当成一次代码审查机会，看看别人为什么这么改、自己为什么那么改，你会从冲突里获得很多对项目演进脉络的理解。
我个人常用的一个小习惯是：每次冲突文件解决完，会打开svn log看一眼这个文件最近几笔提交记录，搞清楚它为什么频繁变动、被谁改了哪些内容。这样既能避免未来再次冲突，也能发现一些潜在的坏味道。
如果你刚开始接触SVN，遇到冲突弹窗不用慌。永远记住一个核心判断维度：这个文件是整个文件的绝大部分内容都要用一边，还是只有局部几个区块需要取舍？ 前者可以用Accept类的整文件选项，后者一定要逐块手动合并。实在拿不准，宁可先备份当前版本再操作，也不要凭感觉盲选。
这个系列如果你觉得有用，后续我可以再展开讲讲树冲突怎么处理、SVN迁移到Git时冲突标记的差异、以及如何让团队从源头减少冲突。欢迎在评论里聊聊你遇到的最难处理的冲突场景，我一一帮你诊断。