研读了blog: 1. http://www.open-open.com/lib/view/open1346982569725.html
2. http://www.360doc.com/content/12/0816/19/1317564_230547958.shtml
3. http://developer.51cto.com/art/201005/201718.htm
4. http://www.cnblogs.com/dafozhang/archive/2012/06/28/2567769.html
5. http://snowolf.iteye.com/blog/953735 (new one)
(个人感觉open经验库里的东西很多都是精挑细选出来的，赞一个)
其实，搞软件开发刚满一年的我，对版本控制并不熟悉。在平时的开发中，仅仅是用IDE集成的subversion来update/commit，极端情况就是遇到subversion出现问题时，就换用“小乌龟”代替。，
上个星期，老板发话，需要把本地server上的代码改动增加到版本库中去。这下抓瞎了。。。真心对版本控制中的branches, tags, merge一窍不通。
本着会用+稍微深入研究的原则，研读了以上blog.
首先，按照address 1中的实验一步步做完，基本能领会分支branches创建与合并的缘由，过程，以及如何使用TortoiseSVN来完成版本控制。
下面我把自己的体会罗列下来，供以后参考：
1. 用TortoiseSVN创建本地仓库，这个仓库用来记录版本（包括/trunk,/branches,/tags中的所有版本）
2. 在新建目录下check out新建仓库（如果用TortoiseSVN，会自动创建SVN标准目录结构：/trunk,/branches,/tags）
3. 此时的/trunk,/branches,/tags均与版本库关联。在/trunk目录下，新建project（可以用IDE），改动后，通过Add和Commit将改动提交到版本库中，并更新版本。
4. 第3步可以理解为起初的开发主要集中在trunk上。之后，由于功能开发模块化，所以每个开发人员可以各自拉出一条分支(branch)进行独立+并行开发。
5. 建立branch时，先在trunk某个版本的基础上，利用TortoiseSVN的branch/tag...功能在版本库的/branches下新建同样的项目目录（这样最好，容易匹配）（这样实际上只是与trunk某个版本建立了软连接，并没有copy代码）；其次，对branch进行update，这才是check out下来代码。到此，branch同trunk的某个版本同步了。
6. 在branch和trunk的并行开发过程中，需要二者相互更新，以避免将来把branch merge回trunk时所造成的一堆冲突。也就是说，为避免branch越走越远，需要branch不断的merge trunk上的改动。用TortoiseSVN操作，请参照address 1中“将trunk中的修改同步到branch”一节。
7. 将开发结束的branch merge回trunk。首先update branch下的项目，然后以它为基础，使用TortoiseSVN的merge功能。
和address 1中的步骤有所不同。最新版本的TortoiseSVN将Reintegrate功能放到Merge Type的下一步了。如下步骤操作：
8. 如果经常执行步骤6，不会产生冲突。但出现冲突时，可以使用TortoiseSVN现解决。
9. 一般此时，branch已经完成任务，可以删除了。
10. 在开发过程中，tag（标签）的作用是作为milestone。每个tag可以认为是一个可用的版本，比如用作demo。tag的制作方式和branch类似。
总结：
-
branch主要用于新功能的开发
-
合并发生在本地working copy，只要你不提交就不会影响到repository
-
合并前一定要先update、commit，保证不会out of day，并将本地的修改保存到repository
-
branch和trunk并行开发的过程中，要经常同步，将trunk的修改合并到branch，合并时选择"Merge a range of revision"
-
branch最后合并回trunk时，merge type选择"Reintegrate a branch"
老板交待任务的背景：1. 稳定版R1已经交付使用，部署到生产服务器上；2. 本地server起初也是稳定版R1，但为满足特殊需求/解决R1中存在的bug，仅在本地server上做了修改（不是patch）。由于特殊原因，两个版本都需要稳定下来。
所以，稳定版R1不做任何改动；本地server上的改动（幸好每次改动都有记录）以branch的形式稳定下来，不merge回R1；正在开发的R2也算作一个版本了。
为顺利完成任务，将步骤预想如下（预计时间1小时）：
1. 查看稳定版R1是否打了tag（如果需要打tag，则命名为*_release_1.0，鉴于将tag设置为readonly比较繁琐，可以暂不考虑）；
2. 新建目录**，在其中新建svn标准目录结构：/trunk; /branches; /tags.
3. 在trunk目录下，新建目录R1，并check out R1的SVN地址 / 直接使用 /tags/*_release_1.0。
4. Based on /trunk/R1 或者 /tags/*_release_1.0，在版本库中创建/branch/dev_R1；然后check out。
5. 将本地server的改动CURD到/branch/dev_R1；
6. Based on /branch/dev_R1，打tag /tags/*_release_1.1.
7. 查看/tags/*_release_1.1的log。