分支并不会自动隔离所有风险。需要先说清开发线、发布标签和修复如何回流。
本文使用Subversion 1.7 客户端与独立测试仓库。SVN（集中式版本管理）的工作副本保存本地修改和基准版本，仓库保存已提交历史。工作副本中的文件状态与仓库修订号需要分别理解。
1. 从现象推到机制
SVN 的分支与标签通常依靠仓库目录复制约定实现，标签不可变更多依赖团队规则和权限。合并记录帮助追踪已合并修订，但不能代替审查；同一修复重复手工复制，可能造成回流混乱。
图中的四个节点分别表示主干版本、功能分支、合并审查、发布标签。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
从明确修订建立演示分支，修复后先 dry-run 查看将产生的变化。标签对应一个可复现版本，不在其中继续开发。
1
2
3
svn copy ^/trunk ^/branches/demo-fix -m "Create demo branch"
svn merge --dry-run ^/branches/demo-fix
svn log --limit 5
以下命令应在专用工作副本执行。先运行 status 和 diff 看清变化，再做更新、合并与提交；不要为了清除冲突标记而放弃尚未理解的双方修改。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 从不同修订创建分支 | 分支起点不同会影响合并基础 |
| 标签目录继续被修改 | 标签名称不再保证固定内容 |
| 修复需要回到主干 | 应审查合并范围并验证 |
对照 1：从不同修订创建分支
分支起点不同会影响合并基础。观察时记录复制来源与修订号。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：标签目录继续被修改
标签名称不再保证固定内容。观察时记录路径权限与后续提交历史。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：修复需要回到主干
应审查合并范围并验证。观察时记录mergeinfo 与实际差异。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
仓库布局是协作约定，不是工具自动强制的产品流程。小团队宜减少长期并行分支，避免把大量精力花在重复集成上。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“修复需要回到主干”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
