1. 项目概述：为什么SVN的trunk/branch/tag不是“三个文件夹”，而是协作开发的底层逻辑

你打开一个老项目的SVN仓库，看到里面整齐排列着trunk、branches、tags三个目录，第一反应可能是：“哦，这是SVN默认建的，照着用就行”。但真正带过团队、维护过半年以上项目的人都清楚——这三个目录一旦用错，轻则合并冲突到凌晨三点，重则上线版本回滚失败、客户数据异常、整周进度清零。这不是危言耸听，而是我亲身踩过三次大坑后写下的第一段话。

trunk、branch、tag，本质不是路径，而是三种不同维度的协作契约。trunk是“我们所有人此刻正在共同签署的最新协议”；branch是“某组人就某个具体目标（比如适配新接口、修复紧急Bug）临时签署的专项协议”；tag则是“这份协议在某个历史时刻被正式公证并封存，不可修改”。它们共同构成SVN版本控制的三根支柱，缺一不可，乱用必塌。

这个内容适合三类人：一是刚从Git转来、对SVN工作流感到困惑的开发者；二是负责搭建公司内部SVN规范的运维或技术负责人；三是参与跨部门协同、需要理解版本交付节奏的产品与测试同学。它不讲抽象理论，只讲你在日常提交、合并、发布时真正会遇到的操作场景、参数含义、命令背后的真实意图。比如为什么svn copy比svn mkdir + svn add更安全？为什么tag目录下禁止svn commit？为什么branch命名必须带日期和功能标识？这些都不是教科书里的规定，而是某次线上事故后，我们围在白板前一条条写下来的血泪共识。

我试过把trunk当临时分支用，结果两人同时改同一处配置，合并时丢了关键字段；我也试过把tag当成备份目录，往里塞了补丁文件，导致下游构建系统拉取到“非纯净快照”；最惨的一次，是误删了branches目录下的某个长期维护分支，而本地没做完整导出——那不是丢代码，是丢掉三个月的客户定制化适配记录。所以这篇内容，每一句操作说明，都对应一个真实发生过的故障现场。接下来，我会带你一层层拆开SVN这台“老式机械钟表”的齿轮，看清每个部件咬合的位置与力道。

2. 核心设计逻辑：为什么SVN坚持用copy而非hardlink，以及它如何影响你的每日操作

2.1 SVN的“快照哲学”与Git的“链式哲学”根本差异

很多人抱怨SVN慢、分支重，根源在于它对“版本”的定义完全不同。Git把每次提交看作一个节点，通过parent指针串成链表，分支只是指向某个节点的轻量指针；而SVN把每次提交看作一次全量快照覆盖，所有文件路径在服务器端都有独立的版本号。当你执行svn copy ^/trunk ^/branches/feature-login-20240520 -m "create login feature branch"，SVN并不是在创建符号链接，而是向服务器发送一条指令：“请为^/branches/feature-login-20240520这个新路径，生成一份与当前^/trunk完全一致的初始快照，并记录这次复制动作的元信息”。

这个设计带来两个直接后果：
第一，分支创建极快，但存储占用真实存在。一次svn copy在服务端实际是O(1)时间复杂度（只记元数据），但磁盘上确实多了一份逻辑副本。实测一个50MB的trunk目录，svn copy出10个branch，服务端磁盘增长约500MB（非硬链接，但SVN内部做了delta压缩，实际增长约300MB）。这和Git clone出10个本地仓库只占50MB有本质区别。

第二，分支合并必须显式指定范围，无法自动推断“共同祖先”。Git能通过commit图谱自动找到merge base，而SVN必须靠人工指定起始版本号。比如你要把branch上的修改合入trunk，命令是svn merge -r 123:HEAD ^/branches/feature-login-20240520，其中123是你当初从trunk创建该branch时的revision号。如果记错了，或者branch中途又从trunk同步过，就会漏合或重复合——这正是我们第一次合并失败的主因：运维同事凭记忆写了-r 100:HEAD，实际创建分支的revision是123，漏掉了100~122之间trunk的两次关键配置更新。

提示：SVN服务端版本号是全局递增的，每提交一次，所有路径的版本号都+1。因此svn info ^/trunk显示的Revision，就是当前trunk的最新全局版本号；而svn info ^/branches/xxx显示的Revision，是该branch最后一次提交的全局版本号。二者数值不同，但都指向同一个全局计数器。

2.2 trunk/branch/tag的权限设计：为什么它们必须物理隔离

SVN仓库的目录结构不是随意组织的，而是权限管控的天然边界。我们在某公司部署SVN时，曾把所有分支混放在^/dev目录下，结果测试同学误删了^/dev/old-bugfix，导致无法追溯历史问题。后来强制推行“三目录范式”，并配合Apache模块配置细粒度权限：

# Apache SVN配置片段（关键部分） <Location /svn/myproject> DAV svn SVNPath /var/svn/myproject # trunk：开发组可读写，测试组只读 <Location /svn/myproject/trunk> Require ldap-group cn=dev-team,ou=groups,dc=company,dc=com </Location> # branches：仅特定分支负责人可写，其他人只读 <LocationMatch "/svn/myproject/branches/feature-.*"> Require ldap-group cn=feature-lead,ou=groups,dc=company,dc=com </LocationMatch> # tags：所有人只读，禁止任何写操作 <Location /svn/myproject/tags> Require all denied # 实际通过pre-commit hook彻底禁用commit </Location> </Location>

这种物理隔离带来的好处是：

• trunk永远干净：只有经过Code Review的代码才能进入，避免“先提交再修复”的野路子；
• branch生命周期可控：每个分支命名含feature-、hotfix-、release-前缀，配合Jira ID（如feature-login-JIRA-123），CI系统能自动识别并触发对应流水线；
• tag绝对可信：所有tag目录由自动化脚本创建（调用svn copy+svn propset svn:externals锁定依赖版本），人工无法svn commit，确保每次发布构建拉取的都是100%可重现的源码快照。

我见过最危险的操作，是某位资深工程师为了“快速验证”，直接在^/tags/v2.1.0目录下svn add了一个临时调试文件。结果第二天构建系统拉取该tag，把调试日志开关编译进了生产包——因为SVN的tag没有“只读锁”，只有靠流程和hook双重保障。这也解释了为什么我们后续在所有pre-commit hook里加了一行硬性校验：

# pre-commit hook核心逻辑（shell脚本） TAGS_PATH="^/tags" if echo "$CHANGED_PATHS" | grep -q "^$TAGS_PATH/"; then echo "ERROR: Direct commits to tags are forbidden. Use 'svn copy' from trunk or branch instead." >&2 exit 1 fi

2.3 为什么tag不是“备份”，而是“法律存证”

很多团队把tag当成代码备份目录，定期svn export打个zip包存档。这是对SVN tag机制的根本误解。Tag的真正价值，在于它提供可验证的、不可篡改的版本锚点。当你执行svn copy ^/trunk ^/tags/v2.1.0 -m "release v2.1.0"，SVN服务端不仅记录了这次复制，还生成了唯一的revision号（比如r1892），这个revision号就是该版本的“数字指纹”。

后续所有操作都围绕这个指纹展开：

• 测试报告里写的不是“基于2024年5月20日的代码”，而是“基于r1892构建”；
• 客户反馈Bug时，支持团队第一句问的是“您使用的是r1892还是r1893？”；
• 安全审计要求提供“v2.1.0版本的完整源码”，你只需svn checkout -r 1892 ^/tags/v2.1.0，得到的结果100%等同于当初发布的那一份。

这种确定性，是zip包备份永远无法提供的。zip包没有revision上下文，无法关联到当时的提交日志、作者、变更文件列表；更致命的是，zip包可能被误覆盖、误修改、误压缩——而SVN的tag revision，只要服务端数据库完好，就永远不可变。

我们曾用这个特性解决过一次重大纠纷：某客户声称v2.0.0版本存在数据泄露漏洞，而我们坚称该漏洞在v2.1.0才引入。双方调取SVN日志，发现r1756（v2.0.0 tag）到r1892（v2.1.0 tag）之间，只有r1823提交修改了加密模块。我们导出r1756和r1823两个版本的加密文件进行二分对比，30分钟内定位到问题代码行——整个过程可追溯、可验证、无可辩驳。这就是tag作为“法律存证”的真实力量。

3. 实操全流程：从创建分支到发布tag，每一步背后的参数深意与避坑指南

3.1 创建分支：不是svn copy完就结束，关键在命名规范与上下文记录

假设你要为“用户登录页UI重构”创建新分支。正确操作不是打开TortoiseSVN点几下就完事，而是严格遵循四步法：

第一步：确认当前trunk状态并记录基线

# 进入本地trunk工作副本 cd /path/to/local/trunk # 更新到最新（确保基线干净） svn update # 查看当前revision和最后提交信息 svn info | grep "Revision\|Last Changed Rev\|Last Changed Author" # 输出示例： # Revision: 1892 # Last Changed Rev: 1892 # Last Changed Author: dev-a

注意：必须用svn update而非svn status，因为后者只显示本地修改，不保证与服务端一致。我们曾因跳过这步，导致分支基线落后trunk两版，合并时出现大量无谓冲突。

第二步：执行svn copy并强制指定消息格式

# 在服务端创建分支（注意：不是在本地工作副本操作！） svn copy ^/trunk ^/branches/feature-login-ui-20240520 \ -m "BRANCH: feature-login-ui, base r1892, JIRA-456, owner: dev-a"

关键参数解析：

• ^/trunk：^符号代表仓库根目录，避免因工作副本路径不同导致路径错误；
• 分支名必须含feature-前缀、功能简述、日期（年月日）、Jira ID——这是CI系统自动识别的关键；
• -m消息中BRANCH:开头是预设关键词，所有pre-commit hook会扫描此标记，自动触发分支创建通知邮件；
• base r1892明确记录基线版本，避免后续合并时猜测。

第三步：立即检出新分支工作副本

# 创建空目录 mkdir /path/to/branch-workspace cd /path/to/branch-workspace # 检出分支（不是update！） svn checkout ^/branches/feature-login-ui-20240520 . # 验证检出版本 svn info | grep "URL\|Revision" # 确保URL含branches路径，Revision为1893（copy操作产生新revision）

警告：绝不能在trunk工作副本里svn switch到分支！switch会保留.trnks目录，导致后续svn status显示大量?状态文件，极易误操作。必须全新checkout。

第四步：设置分支属性并通知团队

# 进入分支工作副本 cd /path/to/branch-workspace # 设置分支负责人属性（供后续自动化识别） svn propset branch:owner "dev-a" . svn propset branch:jira "JIRA-456" . svn commit -m "SETUP: branch properties for automation" # 同时在团队IM发消息：“[分支已建] feature-login-ui-20240520 (r1893), owner: dev-a, 计划6月10日合入”

这个属性设置看似多余，实则是CI流水线的关键输入。我们的Jenkins job会读取branch:jira属性，自动关联Jira任务状态；读取branch:owner，在构建失败时@对应负责人。没有这步，分支就只是个孤立目录。

3.2 日常开发：分支内操作与trunk同步的黄金法则

在分支中开发不是“随便改”，而是要遵循“小步提交、定期同步、冲突前置”三原则。

小步提交：每次提交只包含一个逻辑单元。比如“增加手机号校验正则”、“调整按钮颜色CSS”、“修复密码框焦点丢失”，分别提交，而不是攒一堆改完一起svn commit -m "fix login"。原因很简单：SVN的svn merge是以revision为单位的，如果一个revision混了UI和逻辑修改，后续回滚或选择性合并时会极其痛苦。

定期同步trunk：分支生命周期越长，与trunk的差异越大，最终合并难度指数级上升。我们强制要求：

• 功能分支超过5天未合入，必须每周至少同步一次trunk；
• 同步操作必须用svn merge --reintegrate（针对长期分支）或svn merge -c（针对单次修订）；
• 同步后立即运行全部单元测试，失败则立刻修复，不许带病提交。

典型同步流程（以feature-login-ui-20240520为例）：

# 1. 进入分支工作副本 cd /path/to/branch-workspace # 2. 更新本地分支到最新（确保无未提交修改） svn update # 3. 查看trunk最新revision（假设为r1905） svn info ^/trunk | grep "Revision" # 4. 执行同步（注意：是从trunk向branch合并！） svn merge -r 1893:1905 ^/trunk . # 5. 解决可能出现的冲突（重点检查config.xml、pom.xml等共享配置） svn resolve --accept working config.xml # 6. 运行测试（关键！） mvn test # 7. 提交同步结果 svn commit -m "SYNC: merge trunk r1893:1905 to resolve config drift"

注意：-r 1893:1905中的1893是分支创建时的基线revision，不是当前分支revision。如果分支已提交过，基线revision不变，但起始revision仍为1893。这是最容易填错的坑——有人会写成-r 1895:1905（1895是分支第一次提交号），导致漏合1893~1894之间的trunk修改。

冲突解决技巧：SVN的冲突标记是<<<<<<< .mine、=======、>>>>>>> .r1905。.mine是你的本地修改（即分支上的代码），.r1905是trunk上要合并进来的代码。对于XML/JSON配置文件，我们绝不手动编辑冲突标记，而是用svn diff生成patch，用Beyond Compare逐行比对，确保只保留必要的变更。曾有一次，同事在web.xml冲突中误删了<filter>节点，导致所有请求404，排查耗时4小时。

3.3 合并回trunk：为什么--reintegrate是双刃剑，何时该用-c？

当分支开发完成，准备合入trunk时，选择正确的merge策略决定成败。

场景一：短期功能分支（<3天，修改<10个文件）
用svn merge -c按revision精确合并：

# 查看分支上所有提交revision（假设为r1895,r1897,r1899） svn log -l 10 ^/branches/feature-login-ui-20240520 # 逐个合并（顺序很重要！） svn merge -c 1895 ^/branches/feature-login-ui-20240520 . svn merge -c 1897 ^/branches/feature-login-ui-20240520 . svn merge -c 1899 ^/branches/feature-login-ui-20240520 . # 测试后提交 svn commit -m "MERGE: feature-login-ui r1895,r1897,r1899"

优势：精准控制，避免意外合并；劣势：需人工筛选revision，适合小分支。

场景二：长期维护分支（>1周，多人协作）
必须用svn merge --reintegrate：

# 进入trunk工作副本 cd /path/to/local/trunk svn update # 执行重集成（注意：目标是trunk，源是branch） svn merge --reintegrate ^/branches/feature-login-ui-20240520 . # 解决冲突（此时冲突发生在trunk上，需格外小心） # 提交 svn commit -m "REINTEGRATE: feature-login-ui-20240520 (r1893:1908)"

--reintegrate的本质是：计算branch与trunk的“差异集”，然后将这个差异集应用到trunk。但它有个致命前提——分支自创建后，从未从trunk同步过。如果分支中间执行过svn merge同步trunk，--reintegrate会把trunk的修改又合一遍，造成重复。

因此，我们约定：长期分支一旦启用--reintegrate流程，就禁止再向该分支同步trunk。如果必须同步，只能创建新分支。这是用空间换时间的无奈之举，但比合并爆炸强。

合并后必做三件事：

1. svn log -l 5确认最新提交消息含REINTEGRATE或MERGE关键词；
2. svn diff -r 1908:1909 ^/trunk（假设合并后revision为1909）检查是否有多余文件被添加；
3. 立即触发trunk的CI构建，观察所有测试用例是否通过——这是合并成功的唯一证据。

3.4 创建tag：发布前的最后防线，自动化脚本如何规避人为失误

Tag创建不是开发者的个人行为，而是发布流程的正式环节。我们所有tag均由Jenkins流水线自动执行，脚本核心逻辑如下：

// Jenkins Pipeline snippet stage('Create Release Tag') { steps { script { // 1. 获取当前trunk最新revision def trunkRev = sh(script: 'svn info ^/trunk | grep "Revision" | cut -d" " -f2', returnStdout: true).trim() // 2. 构建tag名称（含日期、版本号、构建ID） def tagName = "v${env.VERSION}-${env.BUILD_ID}-${trunkRev}" // 3. 执行copy（关键：带--parents创建完整路径） sh "svn copy ^/trunk ^/tags/${tagName} -m 'TAG: release ${tagName}, build ${env.BUILD_ID}'" // 4. 设置tag属性（供审计追踪） sh "svn propset tag:build-id '${env.BUILD_ID}' ^/tags/${tagName}" sh "svn propset tag:jenkins-job '${env.JOB_NAME}' ^/tags/${tagName}" } } }

这个脚本解决了三大人为风险：

• 版本号混乱：v2.1.0-123-1892中1892是trunk基线revision，123是Jenkins构建ID，确保每个tag全球唯一；
• 消息不规范：强制TAG:前缀，所有hook可识别；
• 属性缺失：自动注入构建上下文，审计时可反查Jenkins日志。

创建tag后，我们还有个“发布前验证”阶段：

1. 从新tag检出干净工作副本；
2. 执行mvn clean package，生成war包；
3. 用unzip -l target/app.war | head -20检查包内文件是否与预期一致；
4. 运行冒烟测试（smoke test），验证首页、登录页能否正常加载。
   只有这四步全部通过，才允许发布团队下载war包。我们曾卡在这个环节发现：某次tag创建时，svn copy命令因网络超时失败，但脚本未检查返回值，导致后续步骤在空目录执行，生成了空war包——这就是为什么sh命令后必须加|| exit 1。

4. 常见问题与实战排障：那些文档里不会写的“深夜救火”经验

4.1 “合并后文件消失”：不是SVN坏了，是你的工作副本状态错了

现象：执行svn merge ^/branches/xxx后，svn status显示大量文件变成!（missing）状态，甚至整个目录不见了。

根本原因：你正在操作的工作副本，其URL与svn merge源路径不在同一仓库层级。比如你的工作副本是file:///var/svn/myproject/trunk，而你执行svn merge ^/branches/xxx，^指向file:///var/svn/myproject，但SVN客户端会尝试将branches/xxx路径映射到当前工作副本的相对路径，导致路径错乱。

解决方案分三步：

1. 立即停止所有操作，不要svn revert或svn update；
2. 确认工作副本URL：svn info | grep URL，确保它确实是^/trunk或^/branches/xxx；
3. 用绝对路径重新merge：

   # 如果工作副本是trunk，正确命令是 svn merge ^/branches/feature-login-ui-20240520 . # 注意末尾的"."，表示应用到当前目录 # 如果工作副本是branches/xxx，则应为 svn merge ^/trunk .

我们总结出一个口诀：“merge命令的源路径，必须与工作副本的父路径同级”。trunk和branches是同级目录，所以从branches merge到trunk时，源是^/branches/xxx，目标是当前trunk工作副本（.）；反之亦然。

4.2 “冲突标记还在，但svn resolve不生效”：SVN的隐藏状态陷阱

现象：解决完冲突文件，执行svn resolve --accept working file.txt，但svn status仍显示C file.txt，且再次svn resolve提示“no conflicts”。

真相：SVN的冲突状态存储在工作副本的.svn/wc.db数据库中，有时因中断操作（如Ctrl+C）导致数据库状态不一致。此时svn resolve只是清理内存状态，未更新数据库。

终极解法（亲测有效）：

# 1. 强制清除冲突状态（不删除文件内容） svn revert --depth exclude file.txt # 2. 重新标记为已解决 svn resolve --accept working file.txt # 3. 验证 svn status file.txt # 应显示空白（无状态）

--depth exclude是关键，它只重置该文件的状态，不触碰文件内容。我们曾用此法救回过一个被冲突标记污染的pom.xml，避免了手动重建Maven依赖树。

4.3 “tag里怎么多了个文件？”：pre-commit hook失效的连锁反应

现象：某次发布后，审计发现^/tags/v2.1.0目录下多了一个debug.log文件，而该文件从未在任何提交日志中出现。

根因链：

• 开发者A在本地^/tags/v2.1.0工作副本中，执行了echo "test" > debug.log；
• 他误以为svn add debug.log只是本地操作，未意识到tag目录受hook保护；
• 但他的SVN客户端版本较老（1.6.x），pre-commit hook的svn:externals校验未生效；
• 他执行svn commit，hook未拦截，文件被提交。

解决方案是“双重防护”：

1. 服务端hook强化：在pre-commit中增加文件名黑名单：

   # 检查是否在tags目录下提交了禁止文件 if echo "$CHANGED_PATHS" | grep -q "^/tags/.*\.\(log\|tmp\|swp\)$"; then echo "ERROR: Log/temp files are forbidden in tags directory." >&2 exit 1 fi

2. 客户端教育：在团队Wiki置顶公告：“^/tags/目录只允许svn copy创建，禁止任何svn add/commit操作。如需调试，请在branch中进行。”

4.4 “分支合并后，trunk的revision跳变了”：SVN的全局版本号真相

现象：合并前svn info ^/trunk显示Revision 1905，合并提交后变成1908，中间1906、1907去哪了？

答案：那两个revision被本次合并操作本身占用了。SVN的svn merge命令在服务端会产生至少两个新revision：

• 第一个revision：记录svn merge命令的元数据（谁、何时、合并了哪些revision）；
• 第二个revision：记录svn commit提交的合并结果（实际的文件变更）。

所以r1906是merge元数据，r1907是commit变更，r1908是本次提交的消息。这不是bug，而是SVN的设计必然。理解这点，你就不会在监控系统里看到“revision跳跃”就慌张。

我们为此优化了监控告警：不再监控“revision是否连续”，而是监控“trunk的Last Changed Rev是否在X分钟内更新”，因为真正的业务价值是代码是否及时合入，而非revision数字是否整齐。

4.5 “为什么svn log看不到分支的提交历史？”：路径视角的切换艺术

现象：在trunk工作副本执行svn log -l 10，只能看到trunk的提交，看不到分支上的修改。

这是因为svn log默认只显示当前工作副本路径的历史。要查看分支历史，必须显式指定路径：

# 查看分支历史（在任意位置执行） svn log -l 10 ^/branches/feature-login-ui-20240520 # 查看某次合并的详细变更（关键！） svn log -v -r 1908 ^/trunk # 输出会显示：r1908 merged /branches/feature-login-ui-20240520:r1895,r1897,r1899

-v（verbose）参数是灵魂，它显示每次提交修改了哪些文件。我们要求所有Code Review必须基于svn log -v -r XXX输出，而不是只看消息。曾有一次，reviewer只看了-m "fix login"，没注意到-v输出里包含了config.properties的修改，结果上线后数据库连接串被覆盖——从此，-v成为我们Review Checklist的第一项。

5. 工具链与最佳实践：让trunk/branch/tag从“知道”变成“用好”

5.1 TortoiseSVN高级配置：把高频操作变成一键按钮

TortoiseSVN的右键菜单可以自定义，我们为团队预置了四个关键动作：

1. “Create Feature Branch”
命令：TortoiseProc.exe /command:copy /path:"%1" /to:"https://svn.example.com/branches/feature-%date:~-4,4%%date:~-2,2%%date:~-2,2%-" /logmsg:"BRANCH: feature-%date:~-4,4%%date:~-2,2%%date:~-2,2%-, base %REVISION%, owner: %USERNAME%"
效果：选中trunk工作副本，右键→“Create Feature Branch”，自动填充日期、用户名、基线revision，减少手误。

2. “Merge to Trunk (Reintegrate)”
命令：TortoiseProc.exe /command:merge /path:"%1" /url:"https://svn.example.com/trunk" /mergetype:reintegrate /logmsg:"REINTEGRATE: %PATH% (%REVISION%)"
效果：在branch工作副本中右键，一键执行重集成，消息自动带分支路径。

3. “Tag from Trunk”
命令：TortoiseProc.exe /command:copy /path:"%1" /to:"https://svn.example.com/tags/v%VERSION%-%BUILDID%-%REVISION%" /logmsg:"TAG: v%VERSION%-%BUILDID%-%REVISION%, build %BUILDID%"
效果：在trunk工作副本右键，输入版本号和构建ID，自动生成tag。

4. “Show Merge Info”
命令：TortoiseProc.exe /command:mergeinfo /path:"%1"
效果：快速查看当前路径的merge历史，判断是否已同步某次修订。

这些配置保存在%APPDATA%\TortoiseSVN\ContextMenuHandlers.reg中，新成员入职时一键导入，3分钟上手标准流程。

5.2 CI/CD集成：用自动化消灭90%的人为错误

我们用Jenkins构建了完整的SVN流水线，核心环节如下：

其中最关键的“Post-Release”环节，解决了版本号管理的老大难。以前靠人改pom.xml里的<version>，经常忘记或改错。现在tag构建成功后，Jenkins自动执行：

# 更新trunk的版本号 svn update /path/to/trunk sed -i 's/<version>2\.1\.0<\/version>/<version>2\.2\.0-SNAPSHOT<\/version>/' /path/to/trunk/pom.xml svn commit -m "VERSION: bump to 2.2.0-SNAPSHOT for next cycle"

这个自动化，让我们三年内未发生一次版本号混乱事故。

5.3 团队协作公约：写在Wiki首页的七条铁律

最后，所有技术方案都依赖人的执行。我们把以下七条写在团队Wiki首页，每季度回顾：

1. trunk是唯一发布源：任何上线代码，必须经由trunk构建。禁止从branch或tag直接发布。
2. 分支命名即契约：feature-xxx-YYYYMMDD-JIRA-123，缺一不可。名字不对，CI拒绝构建。
3. tag是只读圣殿：^/tags/下禁止svn add/commit/delete。违反者，当日构建失败计入个人OKR。
4. 合并必须带上下文：svn merge后，svn commit -m必须包含MERGE:或REINTEGRATE:前缀及revision范围。
5. 同步是分支生命线：分支存在超3天，必须每周同步trunk一次，否则自动归档。
6. 日志即文档：svn log -v -r XXX输出必须能还原所有变更，禁止-m "fix bug"式模糊消息。
7. 工具即纪律：TortoiseSVN自定义菜单和Jenkins流水线是强制使用项，不接受“我习惯手动操作”。

这七条不是口号，而是我们用两年时间、十几次线上事故换来的共识。当新人入职，导师带他的第一件事，不是讲SVN命令，而是打开Wiki，逐条解读每条背后的事故案例。因为真正的版本控制，控制的从来不是代码，而是人的行为。

我在实际操作中发现，最有效的学习方式，不是死记命令，而是亲手制造一次合并冲突，再按本文方法一步步解开。当你在终端里看到svn status从C变成空白，当svn log -v -r 1908清晰列出所有变更文件，那一刻，trunk/branch/tag才真正从概念，变成你指尖可触的肌肉记忆。