SVN版本控制注意事项

在学生时代，经常会有两三个人共同完成一个软件的开发，每个人都在修改、添加、删除着自己本地硬盘上的代码，当他们把这些代码汇总起来时，汇总的工作需要非常小心，这只是两三人的小团队。在小团队时我们用GIT或者SVN基础功能就可以帮助我们做好版本控制，还不需要使用分支创建和合并功能。在职场中，我们经常是一边开发一边发布，迭代会很频繁，经常会有新功能开发到一半，旧功能爆出Bug要修复。这时不得不先把手上的代码交给版本库，然后切换到旧分支加入Bug的修复工作。这里不可避免要遇到SVN和GIT的讨论，在职场上我其实比较推崇SVN，在学生时代讨论这个话题，总有些人会跳出来，说些特立独行地话，说什么SVN集中的版本控制就是扼杀优秀程序员之类地话。确实SVN版本控制每次提交都要担心Conflict，的确会影响效率，那为什么还要力挺SVN版本控制呢？

在从事PM工作的大半年时间里，SVN和GIT我都深度使用过，简单来说SVN更适用于项目管理，Git适用开源项目代码管理。前面说SVN每次提交都要检查Conflict，这恰可以保证代码永远可以追踪，有利于绩效考核，比如追踪某个Bug是怎么出现的(被谁以及什么时候引入进来的)，同时代码安全上SVN也做得很好，SVN可以按个人进行针对某个子目录的权限控制。对每个人区分读、写权限。更严格的，不支持回退操作。相比之下Git没有严格的权限管理控制，只要有帐号，就可以导出、导入代码，甚至执行回退操作。

常规的SVN仓库目录结构下有3个文件夹：
trunk
tags
branches

其中，trunk(主干|主线) branchs(分支) tags(标记)。
trunk(主干