一.SVN 的工作模型:Subversion 缺省使用复制-修改-合并模型
实际上是文件共享的问题,目前有两种策略:
A.锁定-修改-解锁模型有一点问题就是限制太多,经常会成为用户的障碍:
锁定可能导致管理问题。有时候 Harry 会锁住文件然后忘了此事,这就是说 Sally 一直等待解锁来编辑这些文件,她在这里僵住了。然后 Harry 去旅行了,现在 Sally 只好去找管理员放开锁,这种情况会导致不必要的耽搁和时间浪费。
锁定可能导致不必要的线性化开发。如果 Harry 编辑一个文件的开始,Sally 想编辑同一个文件的结尾,这种修改不会冲突,设想修改可以正确的合并到一起,他们可以轻松的并行工作而没有太多的坏处,没有必要让他们轮流工作。
锁定可能导致错误的安全状态。假设 Harry 锁定和编辑一个文件 A?? Sally 锁定并编辑文件 B,如果 A 和 B 互相依赖,这种变化是必须同时作的,这样 A 和 B 不能正确的工作了,锁定机制对防止此类问题将无能为力—从而产生了一种处于安全状态的假相。很容易想象 Harry 和 Sally 都以为自己锁住了文件,而且从一个安全,孤立的情况开始工作,因而没有尽早发现他们不匹配的修改。
B.复制-修改-合并(CVS,SVN采用)
在这种模型里,每一个客户读取项目版本库建立一个私有工作副本—版本库中文件和目录的本地映射。用户并行工作,修改各自的工作副本,最终,各个私有的复制合并在一起,成为最终的版本,这种系统通常可以辅助合并操作,但是最终要靠人工去确定正误。
二。分支的概念
版本控制系统的一个特性是能够把各种修改分离出来放在开发品的一个分割线上。这条线被称为分支。分支经常被用来试验新的特性,而不会对开发有编译错误的干扰。当新的特性足够稳定之后,开发品的分支就可以混合回主分支里(主干线).
版本控制系统的另一个特性是能够标记特殊的版本(例如某个发布版本),所以你可以在任何时候重新建立一个特定的构件和环境。这个过程被称作标记。
分支中最重要的概念就是独立于主干进行开发,在合并前,不同分支提交的代码互相不可见,互不干扰。但是主干持有所有分支的版本记录,因此主干可以合并分支。比较适用不同团队独立开发各自模块。另外在分支合并的时候需要做回归测试
三。版本库的布局
svn文档是有推荐的目录结构,适用大多数情况:)当然理解了分支的概念,心中有剑也无需受此限制。
There are some standard, recommended ways to organize a repository. Most people create a trunk
directory to hold the “main line” of development, a branches
directory to contain branch copies, and a tags
directory to contain tag copies. If a repository holds only one project, then often people create these top-level directories:
如果一个版本库包含多个项目,人们通常按分支来安排布局:
大致用法如下:
traceview项目 有两个开发人员wya,htyoung ,同时htyoung做为项目管理员,
1.项目开始时htyoung在trunk 创建了最初的文件 这个作为main line,然后 用
svn cp trunk tags/first_init
svn cp tags/first_init branches/wya
svn cp tags/first_init branches/htyoung
创建工作文件夹,我们的开发人员 wya , htyoung 只在他们的开发文件夹 branches/wya,branches/htyoung 内工作,也就是commit.
2.一段时间后由项目管理员(htyoung),merge所有的修改到主线 trunk上,
同时htyoung和wya同主线同步.
3.再过一段时间我们发布0.1版本, 为了有一个记录 项目管理员(htyoung)用以下命令建了一个tags
svn cp trunk tags/Release0.1.0
4.这时又有一个开发人员 JRD来了,项目管理员(htyoung)基于 0.1 给她建了一个工作分支
svn cp tags/Release0.1.0 branches/jrd
5.在我们发布完 0.2 时来了一个 测试员 TA, 我们用以下命令为TA建一个工作文件夹
svn cp trunk tags/Release0.2.0
svn cp tags/Release0.2.0 branches/ta