对CVS,SVN等软件版本管理中Tag，branch,merge的一点理解
对于项目开发过程中，会出现以下的一些情况：
（1）对于某个项目开发了一定的阶段，决定发布一个初始版本V1.0；
（2）V1.0版本上线，对于该项目继续开发（可能增加新的特性、功能升级等升级至V2.0），此时对于原先的代码已经进行了改动；
（3）此时在V1.0中发现了一个BUG，需要马上改动，或者需要在V1.0中紧急加入一个特性，需要对于源代码进行修改了。
没有版本控制，这个时候麻烦来了。考虑一个原始方式（自己上学的时候就这么干过）：
（1）开始对于V1.0版本项目拷贝一个文件夹，作为备份；
（2）对于新的版本开始在V1.0上面开发，这个时候代码或许已经变动很大了；
（3）需要对于V1.0进行修改，则对于原先V1.0备份代码再拷贝一个目录，修改其中BUG，进行加入一个特性；
（4）当对于V1.0的代码修改完成后，转向开发中的V2.0版本，此时，如果将两边的代码进行统一合并，即：对于V1.0的BUG、紧急特性也同时更改到V2.0中；
（5）Ctrl+C、Ctrl+V，删减代码，呵呵。。。混沌了。。。。。基本上确定无疑的会导致代码不一致。
采用CVS、SVN等，可以管理了：
（1）对于V1.0开发完成，进行上线了。此时对于该版本使用“TAG”标记-V1.0_Release，"Tag“为代码某个时间点的快照（不能够在快照上面进行修改）；
（2）继续进行V2.0代码的开发；
（3）需要修改原先的V1.0代码了，此时通过TAG标记获取当时的代码快照（如果此时直接进行修改，然后commit提交会报错，不能直接在TAG版本上面进行修改）；
（4）基于该Tag版本，建立Branch程序分支，作为V1.0_Release_r1；
（5）在V1.0_Release_r1分支上修改BUG，增加紧急特性；
（6）在原先的V2.0代码中并行进行开发，此时两边可以同时进行；
（7）V1.0_Release_r1对于BUG等处理完成之后，发布，作为V1.1上线；
（8）此时原先在V1.0_Release_r1修改的BUG,在V2.0中，仍然存在，再进行”Merge“，增加到V2.0中；
（9）OK。一切都结束了。
