SVN重命名文件引发的树冲突往往没有行级冲突标记（如<<<<<<< .mine），而是表现为结构操作矛盾，需通过svn status识别C >状态，手动分析意图后用svn resolve --accept=working标记解决。
SVN重命名文件引发的树冲突，往往没有
一眼识别重命名树冲突
执行svn status时，注意两类信号：
- 原文件显示为C且带>符号，例如：
C src/Utils.java > local rename, incoming edit upon update - 新文件名（如
src/Helper.java）状态为A（已add但未提交），而服务器上仍存在Utils.java并被他人修改过 - 运行svn update时提示
C path/to/oldname > ... use 'svn resolve' to mark the conflict resolved
分清三类典型重命名冲突场景
每种场景对应不同处理逻辑，不能一概用--accept theirs-conflict硬覆盖：
SVN搭建及使用教学视频(布尔教育)
下载
《SVN视频教程》，SVN:全称Subversion，是代码版本管理软件，管理着随时间改变的数据。这些数据放置在一个中央资料档案库 (repository) 中。这个档案库很像一个普通的文件服务器,不过它会记住每一次文件的变动。这样你就可以把档案恢复到旧的版本, 或是浏览文件的变动历史。许多人会把版本控制系統想像成某种“时光机器”。
-
你重命名了，别人改了原文件（local rename, incoming edit）：说明别人在你rename前就提交了对
Utils.java的修改。你需要把那些修改迁移到Helper.java中，再删掉旧名残留 -
你改了文件，别人重命名了它（local edit, incoming rename）：服务器上已变成
Helper.java，而你本地还编辑着Utils.java。应打开两个文件对比，把你的修改复制进Helper.java，再删掉本地Utils.java -
你和别人各自重命名成不同名字（local rename A→B, incoming rename A→C）：两边都删了
Utils.java、新增了不同文件。需协商统一用哪个新名，保留一个，删掉另一个，并合并逻辑
手动解决+安全标记四步走
树冲突无法自动合并，必须人工干预结构与内容：
- 打开冲突涉及的两个文件（原名+新名），用对比工具逐块检查差异，把必要修改复制粘贴到最终保留的文件里
- 确保工作区只保留一个有效版本：若决定用新名，就
svn delete原文件（如果还存在）；若回退用原名，就svn delete新文件并svn revert重命名操作 - 确认目录结构干净、无重复或残留后，运行：
svn resolve --accept working path/to/conflict（推荐，表示“我已手动理清”） - 再次
svn status验证：原冲突路径不再显示C >，新文件状态应为M或A，旧文件不应再出现在列表中
预防下次再踩坑
重命名是高危操作，提前同步能避免80%的树冲突：
- 重命名前先
svn update，确认没人正在改这个文件；再查svn log -l 5 filename看最近活跃度 - 团队约定重命名流程：比如必须提Issue说明原因，或在重命名前发消息同步
- 对核心工具类、配置文件等敏感路径，建立命名清单文档，避免随意改名
- 使用TortoiseSVN时，右键→Rename会自动记录move操作；避免直接用系统重命名，否则SVN无法追踪
