svn使用规范

开发相关

1.        每天至少获取一次所有相关代码，以降低代码冲突的概率。
2.        本地自动生成的文件不要提交到svn去。svn有个ignore的功能可以屏蔽特定文件。
3.        多提交，每次提交的时候内容少一点。
4.        不要提交不能通过编译的代码。结合多提交的原则，这里其实要求你把工作细分成很小的单元。有个小技巧是函数里面可以先throw new NotImplementException，下次提交再写实现。（抛异常是为了防止以后忘了写实现）
5.        如果提交的时候发现有版本冲突，建议做法是把自己的修改在本地备份一下，然后revert自己的所有修改，然后重新获取，然后把自己的修改重做一遍。因为我们每次只提交少量改动，所以‘根据本地备份的代码重做修改’的工作量很小。这么做的好处是不需要进行复杂的冲突合并操作，不容易引入bug。
6.        每次commit之前，检查一下自己的修改，看是否符合预期，有没有提交错误的东西。因为每次提交的东西很少，所以每次自己提交了什么也很容易检查。
 

发布相关

现在流行主干开发，也就是主要的开发工作都在master分支进行。

用svn做代码版本的发布，一般有两种方式：

• Release Branch

1. 要发布的时候，从master开一个RB.1.1.3之类的分支。然后master继续开发新功能，RB.1.1.3就负责修bug直到版本发布完成。
2. 这个方法适合于比较大型的发布：大项目、大团队、测试和发布周期长。
3. 优点是master和RB之间松耦合。
4. 缺点是master和RB之间经常需要同步代码和修改，这种同步不但繁琐而且容易引入bug。

• Release Tag

1. 要发布的时候，在master上打一个RB1.1.3.1的tag发第一个beta。然后master继续开发。当发现发布的代码有问题时，改代码然后打个RB1.1.3.2的tag发第二个beta。然后master继续开发。这样不管是第几次发布成功了，我们都有对应的tag。
2. 这个方法适合于较小的发布：小项目、小团队、发布周期短。
3. 优点是敏捷。不需要同步代码。
4. 缺点是master的开发容易干扰发布。如果发布周期太长，或者master需要做很大的后续开发，那么就会hold不住。

推荐用Release Tag的方式。发布过程中开发master代码可以先不调用或者if (false)，那么就不会影响发布。