今天把公司的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
当你创建了一个Bug fix分支，你想标记代码在BugFix之前和之后的状态。这样你就很容易的引用你所做的更改，合并到trunk或Release branches。 命名规则： “PRE-”加上Bug ID； “POST-”加上Bug ID。
3. SVN使用规范
先更新，再提交
SVN更新的原则是要随时更新，随时提交。当完成了一个小功能，能够通过 编译并且自己测试之后，谨慎地提交。 如果在修改的期间别人也更改了svn的对应文件，那么commit就可能会失 败。如果别人和自己更改的是同一个文件，那么update时会自动进行合并，如果修改的是同一行，那么合并时会产生冲突，这种情况就需要同之前的开发人员联系，两个人一起协商解决冲突，解决冲突之后，需要两人一起测试保证解决冲突之后，程序不会影响其他功能。
在更新时注意所更新文件的列表，如果提交过程中产生了更新，则也是需要 重新编译并且完成自己的一些必要测试，再进行提交。这样既能了解别人修改了哪些文件，同时也能避免SVN合并错误导致代码有错。
多提交
每次提交的间歇尽可能地短，以几个小时的开发工作为宜。例如在更改UI 界面的时候，可以每完成一个UI界面的修改或者设计，就提交一次。在开发功能模块的时候，可以每完成一个小细节功能的测试，就提交一次，在修改bug的时候，每修改掉一个bug并且确认修改了这个bug，也就提交一次。我们提倡多提交，也就能多为代码添加上保险。
不要提交不能通过编译的代码
代码在提交之前，首先要确认自己能够在本地编译。如果在代码中使用了第 三方类库，要考虑到项目组成员中有些成员可能没有安装相应的第三方类库。项目经理在准备项目工作区域的时候，需要考虑到这样的情况，确保开发小组成员在签出代码之后能够在统一的环境中进行编译。
每次提交必须书写明晰的标注
在一个项目组中使用SVN，如果提交空的标注或者不确切的标注将会让项目 组中其他的成员感到很无奈，项目经理无法很清晰的掌握工作进度，无法清晰的把握此次提交的概要信息。在发现错误后也无法准确的定位引起错误的文件。所以，在提交工作时，要填写明晰的标注，能够概要的描述所提交文件的信息，让项目组其他成员在看到标注后不用详细看代码就能了解你所做的修改。
提交时注意不要提交本地自动生成的文件
例如eclipse中的.classpath文件，Windows生成的缩略图Thumbs.db，项目编 译生成的临时文件.obj, .class等等。如果项目中没有进行这方面的配置来强行禁止提交这样的文件，请自觉不要提交这样的文件。提交了这样的文件后，别人在更新后就可能与本地的环境冲突从而影响大家的工作。不要提交自己不明白的代码
代码在提交入SVN之后，你的代码将被项目成员所分享。如果提交了你不 明白的代码，你看不懂，别人也看不懂，如果在以后出现了问题将会成为项目质量的隐患。因此在引入任何第三方代码之前，确保你对这个代码有一个很清晰的了解。
慎用锁定功能
在项目中要慎用锁定的功能，在你锁定了一个文件之后别人就无法继续修改
提交该文件，虽然可以减少冲突的发生率，但是可能会影响项目组中其他人员的工作。平时只有在编辑那些无法合并的文件（例如图片文件，flash文件等）时，才适当的采用锁定操作。
4. 常规操作
4.1 文件检出
安装TortoiseSVN后，SVN会跟Windows的资源管理器完美集成。点击右键，我们可以在菜单栏中选择“SVN检出”选项，输入要检出代码的文件库的URL地址，我们就可以检出该URL地址下的文件库的文件。默认情况下是检出最新版本的代码，如果需要，我们可以通过浏览日志，根据日志来找出想要的版本，然后在“版本”选项中指定相应版本就可以检出相关代码了1。 之后，对于同一个项目的主干开发，我们都在这个检出的代码文件目录下操作，而不是每一次提交或更新都重新检出一次。
4.2 文件添加
我们在本地创建的文件(包括目录)不会受SVN的控制，为了让其接受SVN的控制必须将其添加到文件库中。对于团队其他成员需要的文件，如代码文件、某些模块的.a文件（由于某些需要，该模块代码不公开），我们必须让它们接受SVN的控制，并且保持最新的版本。
4.3 文件删除
当我们需要删除无用的文件(包括目录)时，不能使用Windows的资源管理工具，而必须使用SVN本身的删除文件功能。这样该文件被删除后，其所有修改历史仍然保存在SVN服务器中，以后仍然可以获得该文件的修改历史。
4.4 文件改名
当我们需要对文件(包括目录)进行改名的时，不能使用Windows的资源管理工具，而必须使用SVN本身的文件改名功能。这样该文件被改名后，其改名前的所有修改历史仍然保存在SVN服务器中，保持连续的修改信息。
4.5 文件更新
其他团队成员提交到SVN上的改动不会自动更新到你的本地拷贝中来，我们需要通过更新文件操作来获取其他成员对项目文件所做的修改。SVN更新文件操作会把��件库里的文件与本地文件进行合并，从而达到了同时保留其他成员的修改及本地的修改的目的。如果无法自动合并则会发生冲突，需要使用文件比较工具进行手工合并，合并完成后才能提交已解决冲突的文件。冲突的详细解决方法见第三章——冲突解决。 在团队开发时，更新是一件很重要的工作，可以保持团队成员之间的工作内容一致，因此要注意经常更新自己的工作拷贝，以保证自己能够获得最新的修改内容。 4.6 改动提交
我们对文件(包括目录)所做的一切改动，包括添加、删除、修改文件都必须提交到SVN服务器文件库中才能正式生效，之后团队的其他成员才可以获取你所作的修改。
提交是很重要的一项操作，要求做到：
1)提交代码之前一定要保证修改后的代码能编译通过，不能提交编译不通过的代码。 比较修改前及修改后的代码，把调试信息或其他不相关的信息去掉，再次确保提交的代码是
正确的并且提交的是需要提交的文件。
2) 不要等到修改了很多代码才提交，而是相关小功能完成时就应该提交一次。这样以后发现问
题时就很容易撤销有问题的代码——因为撤销只能针对一次提交，所以在一次提交里涉及过多的功能是不推荐的。
3) 提交时必须填写log信息，说明这次提交增加了什么功能或者修正了什么bug。这些信息有助
于自己和其他团队成员了解整个项目的历史。当出现问题时也方便定位到对应的版本代码，所以log信息必须足够详细。
4) 事务性提交。也就是说提交要么成功，要么全部失败——即提交出现错误时会自动回滚，实
际上没有提交任何东西。出现错误时，解决错误，再次提交上次提交的全部内容即可。
附录：测试自动化小组SVN使用指导原则
1.Project的构建
Project在SVN服务器上的目录架构如下：
SVN上的项目文件：
1. 必须保证Trunk上的代码是最新的！定期对Trunk上的代码进行更新，各小组可根据各自实际
情况自己把握
2. Tag是根据项目需要所打的标签，每一个发布的版本都要打Tag，主要是方便有需要时可以
直接根据Tag返回到之前的状态，以便于分析、测试；Tag中必须包含相应的release文件及当时编译或发布时的源代码，必须有相关的文档注明项目背景、发布情况等。
3. Branch文件夹可以用作备份用，可以用个人名字命名文件夹；此外，Branch分支主要用来
进行短暂或者探索性的开发使用，最终的软件版本必须更新、合并到Trunk主干上。 4. 关于同一项目组开发环境的建议：同一项目组成员的开发环境最好一致，软件安装路径和
Project文件存放路径最好一致。
2. 版本号
关于版本号命名规则：主版本号.子版本号.修正版本号
1. 项目初版本时，版本号为0.1.0；
2. 当项目在进行了局部修改或 bug 修正时，主版本号和子版本号都不变，修正版本号加 1；
3. 当项目在原有的基础上增加了部分功能时，主版本号不变，子版本号加 1，修正版本号复位
为 0；
4. 当项目在进行了重大修改或局部修正累积较多，而导致项目整体发生全局变化时，主版本号
加 1，子版本号和修正版本号复位为0；
5. 编译版本号一般是编译器在编译过程中自动生成的，我们只定义其格式，如果编译器不能自
动生成，人手添加，数值代表为当前的系统时间。 例子：V1.0.1 Build090305 Rel111123 其它版本使用规则： 1. α（alphal）内部测试版
此版本表示该软件仅仅是一个初步完成品，只在组内内部交流，该版本软件的 bug 较多，限内部测试使用。
例子：V0.1.1 Build090305 alphal1 2. β（beta）外部测试版
该版本相对于α版已有了很大的改进，经过组内的测试，消除了严重的错误，但还是存在着一些缺陷，需要经过大规模测试来进一步消除。 例子：V0.1.2 Build090305 beta1 3. demo 演示版
仅限评审或讲解时做介绍使用。 例子：V0.1.3 Build090305 demo1 4. release 最终版
该版本意味“最终释放版”，在出了一系列的测试版之后，终归会有一个正式版本，一般情况下，release不会以单词形式出现在软件封面上，取而代之的是符号 (Rel) 。release版本发布时，必须将待发布的软件和相应版本更新记录打包在一起发出。 例子：V1.0.1 Build090305 Rel111123
3. 权限限制
如果项目本身需要对项目组成员作不同的权限控制，可以考虑维护两个工程：一个工程里面有相应的源文件，一个则只有编译后的文件。
4. 模块的版本维护
1. 文件一般不需要版本，但要有详细的更新历史记录； 2. 模块可以以版本来维护，具体可以不同的文件夹区分。