零、说明：-----欢迎拍砖
1、下面内容是找的网上资料总结的，不是生产环境内容，svn分支策略好麻烦啊
2、merge 很重要而且不好理解，merge修改的只是本地的工作副本，所以只要不提交，不会对服务端造成影响
3、多个项目互相依赖，会不会混乱，版本怎么管理那？？？？
一、Trunk，Branches，Tags说明
1、Branches、Tags生成都是使用svn copy命令生成的，Branches--->分支和、Tags--->标签；
2、通常Branches是可以继续修改的、Tags不可以再修改，这是服务端的权限控制的，Tags只有管理员有写权限；
3、branches冻结：去除写权限；
二、不同分支策略说明
a、不稳定主干策略：广泛应用于开源项目，没有分支合并的工作量；
上图说明：以下内容的左侧数字和图中的数字标注意义对应（trunk被水印挡住了）
0----->以trunk为基础，进行开发进行，等达到稳定状态，此时复制一个0.9 版本发布分支（/branches/0.9），进行发布前最终测试，测试完成后打标签(/tags/0.9.0)，并 使用标签的程序做为最终的发布程序；
1----->0步骤，拷贝分支后，继续进行新的开发（dev1.0），直到达到发布程度（稳定）；
2----->dev1.0版本达到发布状态，此时复制一个1.0版本的分支（/branches/1.0）,准备开始测试；
3----->1.0版程序发布前的严酷测试，我认为此时应在IDC机房测试环境测试也就是最接近生产场景的环境测试；
4----->测试完毕，1.0版代码最终版确定，打标签保存（/tags/1.0.0）,并使用标签代码发布程序，此时分支代码冻结（去除读写权限）或删除分支；
5----->2步骤完成后，在trunk上继续新版本（dev2.0）的开发和bug修复，此时如果遇到严重bug，就要了考虑是否对之前的发布版本进行升级了，如1.0.0----->1.0.1；
6----->dev2.0版本达到发布状态，此时复制一个2.0版本的分支（/branches/2.0）,准备开始测试；
7----->2.0版程序发布前的严酷测试，我认为此时应在IDC机房测试环境测试也就是最接近生产场景的环境测试，测试时，突然接到消息，现有程序存在bug，且此bug可以快速解决，因此在1.0版基础上修复bug，否则要在trunk上修复bug，2.0版发布需要延迟或中断，需要领导决定；
8、9、10----->中断测试，在现有代码上进行bug修复，此地图形是分支，单不要开启分支，直接在2.0代码进行bug修复，直到修复后，继续进行发布测试；
11----->7步骤发现的bug修复完毕，继续进行严格的发布前测试，知道测试完毕；
12----->测试完毕，2.0版代码最终版确定，打标签保存（/tags/2.0.0）,并使用 标签代码 做为最终的发布程序；
13----->将7步骤修复的bug运送到1.0版本代码中，修复1.0版本中的bug，修复后进行发布测试，如果bug是在1.0程序发布后新增的功能，那1.0和之前版本就不存才bug，也就不用修复；
14----->测试完毕，1.0版代码最终版确定，打标签保存（/tags/1.0.1）,并使用标签代码发布程序；
15----->将7步骤修复的bug运送到0.9版本代码中，修复0.9版本中的bug，修复后进行发布测试；
16----->测试完毕，0.9版代码最终版确定，打标签保存（/tags/0.9.1）,并使用标签代码发布程序；
17----->将7步骤修复的bug运送到trunk代码中，继续新版本（dev3.0）代码开发；
此策略的缺点：
1、必须对主干上的新功能增加进行控制。只能增加下一个发布里面计划集成进去的新特性；------否则永远不会稳定
2、已经在主干上集成的新特性中的任何一个，如果达不到里程碑的要求，稳定分支就不能创建，这很有可能影响下一个发布的计划；
3、bug修改必须在各个分支之间合并；
4、从分支和合并的一些实践经验上看，各个长期存在的分支之间必须要周期性的进行合并，否则很容易引发合并冲突。可是各个stable分支以及release分支之间恰好是不能进行合并而且还要长期存在的
5、采用这种分支策略可能碰到的最大问题就是某个分支上的bug修改内容往其它分支merge的时候出现的冲突
6、一旦发现一个bug，调查这个bug影响哪些分支的工作会随着维护的发布分支的数量而增加
7、在非产品开发的外包软件项目里面，这种发布方法的好处体现不出来，而缺点仍然存在
8、产品的发布，只要把发布分支上的代码编译成安装盘就可以了，而外包的发布往往是把上一次发布和这一次发布之间发生变化的代码送给客户。如果每次发布都是一个分支的话，将会出现两个分支上的比较，针对外包开发的特殊情况，只有采用另外一种分支管理策略；
b、稳定主干策略---------------------可以有很多变化，根据实际情况确定怎样实现
上图说明：以下内容的左侧数字和图中的数字标注意义对应，此图中trunk不做为开发目录使用，时刻保持稳定状态，只有管理员有写权限，其他人只有读权限（tags被水印挡住了）
0----->0步骤，此时trunk是稳定状态，程序版本为0.9.0，对应的标签为/tags/0.9.0 ;
1----->按照开发计划，准备开发1.0.0版本程序，新功能或修复bug，此时copy一个发布分支做为开发测试主干（/branches/realease_1.0.0），注意：trunk上的代码保持不变，直到步骤5；
2----->此时，以发布分支为基础，根据开发计划，针对不同的功能，建立不同的分支，此时建立缓存任务分支（/branches/realease_1.0.0_cache）；
3----->开发人员在分支/branches/realease_1.0.0_cache上进行cache功能开发，直到开发完毕；
4----->分支/branches/realease_1.0.0_cache开发完毕，由项目管理人员将cache功能分支代码（/branches/realease_1.0.0_cache）和发布分支（/branches/realease_1.0.0）进行merge操作，进行分支代码合并，如果有冲突要解决掉，代码合并后进行严格测试（IDC测试环境，此时的测试一定要严格，因为它是该版本代码最终测试）；
5----->完成发布前测试，将开发完毕的发布分支（/branches/realease_1.0.0）代码，合并（merge）到trunk代码中，此时trunk中的代码版本是1.0.0；
6----->对此时的trunk中的代码打标签（/tags/1.0.0），原发布分支（/branches/realease_1.0.0）删除或冻结（去除写权限）；
7----->按照开发计划，准备开发2.0.0版本程序，新功能或修复bug，此时copy一个发布分支做为开发测试主干（/branches/realease_2.0.0），注意：trunk上的代码保持不变，直到步骤18；
8、9----->此时，以发布分支为基础，根据开发计划，针对不同的功能，建立不同的分支，此时建立支付任务分支（/branches/realease_2.0.0_pay）和短信任务分支（/branches/realease_2.0.0_sms）；
10、11----->开发人员在分支/branches/realease_2.0.0_pay上进行支付功能开发，在分支/branches/realease_2.0.0_sms上进行短信功能开发，直到开发完毕；
12----->分支/branches/realease_2.0.0_pay开发完毕，由项目管理人员将pay功能分支代码（/branches/realease_2.0.0_pay）和发布分支（/branches/realease_2.0.0）进行merge操作，进行分支代码合并，如果有冲突要解决掉（如果出现冲突一定要找到原因，因为理论上不会出现冲突，除非有其他人修改了发布分支代码，查看发布分支修改日志，并开会评估影响范围，是否继续合并代码）；
13----->此时分支/branches/realease_2.0.0_sms未开发完毕，因此需要将发布分支（已增加pay功能）的代码合并到sms功能分支，并解决可能出现的冲突，然后继续开发sms功能；
14----->分支/branches/realease_2.0.0_sms开发完毕，由项目管理人员将pay功能分支代码（/branches/realease_2.0.0_sms）和发布分支（/branches/realease_2.0.0）进行merge操作，进行分支代码合并，如果有冲突要解决掉（如果出现冲突一定要找到原因，因为理论上不会出现冲突，除非有其他人修改了发布分支代码，查看发布分支修改日志），代码合并后进行严格测试（IDC测试环境，此时的测试一定要严格，因为它是该版本代码最终测试），2.0.0版本程序发布前最终测试阶段，突然接到bug修复任务（必须是修改时间短，影响小，否则放到下一版本开发或推迟该版本发布时间），此时中断测试工作进行bug修复功能；
15----->此时，以发布分支为基础，此时建立bug修复任务分支（/branches/realease_2.0.0_bugfix）；
16----->开发人员在分支/branches/realease_2.0.0_bugfix上进行bug修复，直到修复完毕；
17----->分支/branches/realease_2.0.0_bugfix开发完毕，由项目管理人员将bugfix分支代码（/branches/realease_2.0.0_bugfix）和发布分支（/branches/realease_2.0.0）进行merge操作，进行分支代码合并，如果有冲突要解决掉（如果出现冲突一定要找到原因，因为理论上不会出现冲突，除非有其他人修改了发布分支代码，查看发布分支修改日志），代码合并后进行严格测试（IDC测试环境，此时的测试一定要严格，因为它是该版本代码最终测试）；
18----->完成发布前测试，将开发完毕的发布分支（/branches/realease_2.0.0）代码，合并（merge）到trunk代码中，此时trunk中的代码版本是2.0.0；
19----->对此时的trunk中的代码打标签（/tags/2.0.0），原发布分支（/branches/realease_2.0.0）删除或冻结（去除写权限）；
此策略的缺点：
1、如果某个开发分支因为功能比较复杂，或者应发布计划的要求而长期没有合并到主干上，很可能在最后合并的时候出现冲突；
2、如果有的分支确实因为特殊的需要必须长期存在，那就必须定期把主干的更新往这个分支上合并；
3、这种发布模式的测试分支往往是各个发布分支，在正式发布之前才把下一个发布分支上的更新合并到主干，这就引入了合并出错的风险，而主干上的程序是没有经过测试的；
4、管理复杂，merge的时候很麻烦，容易死人；
三、分支策略使用时注意事项-----------------**很重要**
1、在分支上做开发的时候，必须定期使分支与主干同步，避免开发完成后合并(merge)回主干时出现严重冲突(confict)；
2、进行合并前，处理掉工作副本上的所有本地修改，方便合并失败时进行回滚(revert)；
3)、进行合并时，特别注意 新增/删除 操作，因为很多冲突都是这类操作引起的；
4、完成一个分支的功能并合并回主干后，抛弃该分支，后续其它功能的开发使用新建的分支。当然，也有办法继续使用该分支；
5、辅助文档是必需的。为了观察分支的创建和合并的过程，至少需要一份类似泳道图的文档标记每一次分支创建和合并的过程；
6、开发分支往主干或者发布分支合并的次数应该尽可能少。一般来讲应该在单体测试结束合并到主干或者发布分支，然后进行结合测试。如果结合测试里发现bug不应该在原来的开发分支上继续修改，而应该创建新的分支进行修改；
7、分支创建和合并的log必须规范。便于以后查找。基本的log信息应该包括从哪个分支的哪个版本创建分支；把哪个分支的从哪版本到哪个版本范围内的变更合 并到了哪个分支的哪个版本，合并后的版本号。这些信息有一些是版本控制工具本身可以很方便查找到的，就可以省略；
四、分支策略测试
1、环境说明：
svn服务器：192.168.11.161-------------------svnserver
2、配置说明：
建立测试版本库:（）
[root@mb svndata]# ll total 8 drwxr-xr-x 6 root root 4096 Feb 20 18:04 access_control_test drwxr-xr-x 6 root root 4096 Jan 31 20:57 sadoc [root@mb svndata]# [root@mb svndata]# svnadmin create /application/svndata/branches_test [root@mb svndata]# ll total 12 drwxr-xr-x 6 root root 4096 Feb 20 18:04 access_control_test drwxr-xr-x 6 root root 4096 Feb 27 16:47 branches_test drwxr-xr-x 6 root root 4096 Jan 31 20:57 sadoc [root@mb svndata]# pwd /application/svndata [root@mb svndata]#
说明：版本库 access_control_test使用sadoc版本库的配置文件，这样认证文件就是用同一个文件了，同时拷贝钩子文件（message消息长度验证）
[root@mb svndata]# cp -a sadoc/conf/svnserve.conf branches_test/conf/ cp: overwrite `branches_test/conf/svnserve.conf'? y [root@mb svndata]# cp -a sadoc/hooks/pre-commit pre-commit pre-commit.tmpl [root@mb svndata]# cp -a sadoc/hooks/pre-commit branches_test/hooks/ [root@mb svndata]# [root@mb svndata]# chmod +x branches_test/hooks/pre-commit [root@mb svndata]#
修改权限及用户文件：
[root@mb svnpasswd]# pwd /application/svnpasswd [root@mb svnpasswd]# [root@mb svnpasswd]# vim authz [root@mb svnpasswd]# tail -3 authz [branches_test:/] @group1 = rw @group2 = r [root@mb svnpasswd]# [root@mb svnpasswd]# sed -n '34,35p' authz group1 = test1,test2 group2 = test2,test3 [root@mb svnpasswd]# [root@mb svnpasswd]# cat passwd ### This file is an example password file for svnserve. ### Its format is similar to that of svnserve.conf. As shown in the ### example below it contains one section labelled [users]. ### The name and password for each user follow, one account per line. [users] # harry = harryssecret # sally = sallyssecret oldboy = 123 gongli = 123 mamengmeng = 123 test1 = 123 test2 = 123 test3 = 123 [root@mb svnpasswd]#
重启svn版本库：
[root@mb ~]# pkill svnserve [root@mb ~]# netstat -tnlp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1008/sshd tcp 0 0 :::22 :::* LISTEN 1008/sshd [root@mb ~]# svnserve -d -r /application/svndata/ &>/dev/null [root@mb ~]# netstat -tnlp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1008/sshd tcp 0 0 0.0.0.0:3690 0.0.0.0:* LISTEN 15411/svnserve tcp 0 0 :::22 :::* LISTEN 1008/sshd [root@mb ~]#
初始化版本库：建立基本目录结构
[root@mb ~]# mkdir -p branches_test/trunk branches_test/branches branches_test/tags [root@mb ~]# ll branches_test/ total 12 drwxr-xr-x 2 root root 4096 Feb 27 17:18 branches drwxr-xr-x 2 root root 4096 Feb 27 17:18 tags drwxr-xr-x 2 root root 4096 Feb 27 17:18 trunk [root@mb ~]# svn import branches_test file:///application/svndata/branches_test/ -m "import base dir" Adding branches_test/trunk Adding branches_test/branches Adding branches_test/tags svn: Commit blocked by pre-commit hook (exit code 255) with no output.
提交报错，给钩子脚本pre-commit增加执行权限
[root@mb svndata]# chmod +x branches_test/hooks/pre-commit [root@mb svndata]# pwd /application/svndata [root@mb svndata]# [root@mb ~]# svn import branches_test file:///application/svndata/branches_test/ -m "import base dir" Adding branches_test/trunk Adding branches_test/branches Adding branches_test/tags Committed revision 1. [root@mb ~]#
checkout版本库到本地：
[root@mb ~]# svn co svn://10.0.0.7/branches_test/ branches_test/ Authentication realm: <svn://10.0.0.7:3690> 5bb7c570-01de-468e-a346-5a680f32622f Password for 'test1': A branches_test/trunk A branches_test/branches A branches_test/tags Checked out revision 1. [root@mb ~]#
3、测试说明：
1）windows本地建立工作目录：
2）主干(trunk)中增加文件1.txt:
3）不稳定分支测试：（估计测试时晕了，这测试过程不对）
创建分支（/branches/0.9）:
建立文件，并设当修改，模拟上线前测试修改:
打标签（/tags/0.9.0）:
查看创建标签的日志：-------------这个很像之前遇到的replacing导致日志被截断的问题
更新新建的标签（/tags/0.9.0）到本地：
标签创建完毕，把分支的更改（使用新建的标签，因为他是最终版，分支可能有人改动）合并到主干：
Test merge：
Merge结果：增加文件2.txt，修改1.txt
merge后，提交到版本库：merge修改的只是本地工作拷贝，不提交的话，线上版本库不会变化；
查看日志：merge日志--------能看到分支的操作日志
4）稳定分支测试： 参考不稳定分支测试过程，merge原理一样；
