这篇文章整理一下使用svn在项目中相关的分支模型实践经验。
实践经验1：仓库结构
仓库基本目录层次的构成在项目启动之初就需要进行考虑，根据项目后续的是否进行更复杂的目录结构层次划分进行决定。比如：抉择如下的构成：
| 目录1 | 目录2 |
|---|---|
| trunk | 模块1 |
| 模块2 | |
| branches | 模块1 |
| 模块2 | |
| tags | 模块1 |
| 模块2 |
或者
| 目录1 | 目录2 |
|---|---|
| 模块1 | trunk |
| branches | |
| tags | |
| 模块2 | trunk |
| branches | |
| tags |
实践经验2：分支结构
根据具体情况决定是否采用gitflow还是传统svn的trunk/branches/tags的结构方式。但是这也不是必须的，如果持续集成做的较好，并且尽可能的减少，尤其是每日构建频度较高的小型团队，强烈建议化繁为简，一条主线进行开发/测试/发布，尽量减少长时间存在的临时分支，也能很好地减少浪费。
实践经验3：代码提交
代码的提交尽可能的考虑到如下两个主要因素：
可维护性：详细和规范化comment的内容，可以更好地对提交的信息进行把握。有条件的可以考虑在hook中添加对代码comment的强制检查。svn相关的comment模版也已经在开发列表中，后续可以考虑引入。
可回滚性：代码的提交建议尽可能以一个逻辑功能点为提交，出现问题会滚到上一个版本应该能够解决当前版本引起的问题。完全较为困难，所以主要希望开发者首先要从意识上进行强化。
实践经验4：issue关联
与Ticket管理工具诸如Jira/Redmine/Trac/Mentis/禅道等相关联，提交的信息以固定的格式包含issue id，在comment不足以解释代码片段修改的前因后果时，Ticket管理工具所包含的详细信息将能起到很好的作用。
实践经验5：merge可追踪
merge信息可跟踪：虽然svn没有诸如git那样的no-ff的合并选项，但是建议以规范的方式可很容易的对一次完整功能性提升（特性开发或者bug修正）的整体进行：
状况把握：修改了多少文件和具体的详细信息
回滚：一旦出现问题，可以整体会滚到对应前的状态，而不必过多做很多手工合并或者修改的作业。
实践经验6：备份/恢复
定期备份：此部分功能尽可能做到如下要点，不然一般来说功能形同虚设
恢复功能：备份的数据进行过验证，至少不会发生完整性的问题。比起数据丢失，根本不能使用的备份数据才是非常可怕的。因为备份以及恢复功能很少使用，所以考虑不足的可能性很大。
数据丢失：可能的情况下做到实时的数据备份最为理想，但是在做不到的时候。请至少保证每日备份。
备份保存：有条件的话在硬件上考虑具有raid功能的，或者在软构成上实现mirror方式。保存请至少在不同机器上也有一个备份，以降低单点故障带来的灾难性概率。
备份轮转：需要考虑备份轮换，不然长时间运行时可能会导致出现问题。
实践经验7：团队开发
选择copy-modify-merge方式还是lock-modify-unlock，虽然svn基本上是以前者为主，而且后者也会对沟通产生很多不必要的成本，但是这个是团队已经建立默契而且成员相关的意识和技术都没有问题的前提下的。当相互覆盖这样的低级问题频出的时候也可以考虑使用一下，因为至少它给出了一个信号：这个文件不是只有我一个人在改，我的操作可能会影响到别人。
实践经验8：安全
权限的控制非常重要，所以在团队权限设定的时候，灵活并且方便的权限设定非常重要。更为重要的是信息的安全，什么样的用户该有什么样的权限，匿名用户的权限，以及在前面的例子中为了简单演示，使用的都是用户密码明文保存的方式，这些在生产环境中建议尽可能消除，尤其是网络有可能被直接访问到的情况。
参考文章
https://svn.apache.org/repos/asf/subversion/trunk/doc/user/svn-best-practices.html