今天把公司的SVN服务器配置给做了一下，根据公司部门的不同，划分了不同的访问目录，并给不同目录配置了相应的权限，算是把这份差事给干完了，但其实我对自己的工作是不满意和有遗憾的，因为目前公司的SVN服务器的配置还不符合代码的管理规范，没有分支，没有标签，我做事情总想把事情做到极致，至少顶层设计要合理，方便后来人，但目前要实现我的想法作为公司小罗罗的我是没有资格去推动的，不得已以这篇文章来意淫一下吧，幻想如何利用SVN工具做出规范的源代码管理。
1. SVN概述
随着项目的规模越来越大，以前靠邮件传送修改代码的方式显得捉襟见肘了，已经严重影响了我们的工作效率，以后我们将使用SVN来管理项目的开发。
SVN全称是Subversion，是一种版本控制系统，可以给团队开发项目时带来很多好处： 它给团队提供了一个项目级别的撤销功能，没有什么是最终确定了的，错误可以很容易被回滚。即无论团队成员什么时候所做的修改，都可以撤销。
它使得多个程序员可以有序地同时为同一个程序写代码。团队不再会因为某人覆盖了其他团队成员所做的编辑而丢失做过的工作。
版本控制系统记录着每时每刻的改动。如果你遇到了一些修改过的代码时，要找到是谁何时写的就会很方便，还可以通过日志了解为什么要这样写。
版本控制系统可以让你能够保持主线开发进行的同时发布多个版本。有了版本控制系统，就无须在发布之前让团队停止工作以冻结代码了。
版本控制系统是一个项目级别的时间机器，可以让你输入一个日期就可看到项目当时的样子。
SVN虽然说能帮助我们的团队更有效地协作，但是如果使用不当，它不仅没给我们带来任何的方便，反而会降低我们的工作效率，因此编写此规范，目的是方便大家的工作。
2.目录规范
正规项目的SVN目录结构一般有三个文件夹:1.trunk，2.branches，3.tags，在一个规范的项目中这些目录是必不可少的，兼顾效率和代码安全。下面我来介绍一下他们的作用。
2.1Trunk
任何时候Trunk里包含的都是最新的开发代码。这里的代码将会工作到你的下一个主要发布版本。 据我所见，几乎常常人们只使用trunk来存放他们的代码。发放了一个版本后继续在其上进行下一版开发。这不好，无论是对你还是你的产品。 Trunk应该只被用来开发将会成为你的下一个重要版本的代码。不要给trunk加上版本号和发布名称。仅需要保证trunk在任何时候都处于“开发模式”。 例子： https://svn.example.com/svnroot/project/trunk
2.2 Branches
这里有几种不同类型的分支。这里我会告诉你一些常见的类型。在branches的目录里，你可以为更多具体的目标创建路径，像即将发行版本。正如我的文章“article on releasing software from Subversion”里讨论的那样，brahches路径包含了trunk在不同发展阶段的副本。
2.2.1 Release Branches
我们已经见过了 RB-x.x release branches。当trunk达到准备发布的阶段时（或者你想冻结新特色的添加时），你应该创建一个release branches。 Release branches只是你当前trunk的一个副本。 这个branches可以被单独的签出你也可以启动branches和基于此版本的项目。你还可以使用此分支在测试期间修复Bug。这种方式能够保证trunk继续开发，而不会被发布某个具体的版本所干扰。因此当你准备发布一个新版本时，这样不会影响你trunk增加新的功能。
2.2.2 Bug fix branches
分支也可以用于处理trunk或release branches里发现的严重的Bug。这些Bug很复杂，你不能在一次提交时就修复他们。因此为了集中精力修正此错误，你应该为此问题创建一个新的分支。这样就不会影响trunk 和 release branches的继续进行，并且你也不会因为发现新的Bug 和测试而干扰此Bug 的修复。 Bug 修复分支的命名通常遵循下列方式：使用你的缺陷管理系统分配给此Bug的ID。通常这是一个数字。如：Bug-3391。 当然，你也可以象其它分支一样访问你的Bug分支。
2.2.3 Experimental branches
有时你想将某个新技术引进项目。这很好，但是你当然不想赌上你的整个项目。想象一下，你想把你的Web程序从PHP4改为PHP5。你要花多少时间？在这期间你的trunk停止使用？直到你把所有到PHP5的转换做完！ 这是实验，可能PHP5就像彩虹的另一端一样离你的程序太远了，你应该给他创建一个分支。你可以在分支里进行更改，如果失败了，你在当前分支仍然有PHP4的代码。 如果失败了，实验分支可以抛弃。如果成功，你可以很容易的将其合并到trunk并继续你的新技术。实验分支命名遵循在面原则：为其名字加上前缀“TRY-”。
2.3 Tags
标签就像分支一样备份你的代码。但是 Tag不被用来开发，他们只是用来标记你代码的状态。
1.3.1 Release tags Release Tags
标记你版本发布点的代码。 Release Tag 永远是相应发布分支的副本。 Release Tag命名规则：“REL-”前缀加上版本号。
1.3.2 Bug fix PRE and POST tags