### 版本模型
版本控制系统的核心任务是提供协作编辑和数据共享,但是不同的系统使用不同的策略来达到目的。
### 文件共享的问题
所有的版本控制系统都需要解决这样一个基础问题:怎样让系统允许用户共享信息,而不会让他们因意外而互相干扰?版本库里意外覆盖别人的更改非常的容易。
考虑[图2.2 “需要避免的问题”]( "图2.2.需要避免的问题")的情景,我们有两个共同工作者,Harry和Sally,他们想同时编辑版本库里的同一个文件,如果首先Harry保存它的修改,过了一会,Sally可能凑巧用自己的版本覆盖了这些文件,Harry的更改不会永远消失(因为系统记录了每次修改),Harry所有的修改*不会*出现在Sally的文件中,所以Harry的工作还是丢失了―至少是从最新的版本中丢失了―而且是意外的,这就是我们要明确避免的情况!
**图2.2.需要避免的问题**
![需要避免的问题](https://box.kancloud.cn/2016-08-21_57b8a3339850f.png)
### 锁定-修改-解锁 方案
许多版本控制系统使用*锁定-修改-解锁*这种机制解决这种问题,在这样的系统里,在一个时间段里版本库的一个文件只允许被一个人修改。首先在修改之前,Harry要“锁定”住这个文件,锁定很像是从图书馆借一本书,如果Harry锁住这个文件,Sally不能做任何修改,如果Sally想请求得到一个锁,版本库会拒绝这个请求。在Harry结束编辑并且放开这个锁之前,她只可以阅读文件。Harry解锁后,就要换班了,Sally得到自己的轮换位置,锁定并且开始编辑这个文件。[图2.3 “锁定-修改-解锁 方案”]( "图2.3.锁定-修改-解锁 方案")描述了这样的解决方案。
**图2.3.锁定-修改-解锁 方案**
![锁定-修改-解锁 方案](https://box.kancloud.cn/2016-08-21_57b8a333ad149.png)
锁定-修改-解锁模型有一点问题就是限制太多,经常会成为用户的障碍:
-
*锁定可能导致管理问题。*有时候Harry会锁住文件然后忘了此事,这就是说Sally一直等待解锁来编辑这些文件,她在这里僵住了。然后Harry去旅行了,现在Sally只好去找管理员放开锁,这种情况会导致不必要的耽搁和时间浪费。
-
*锁定可能导致不必要的线性化开发。*如果Harry编辑一个文件的开始,Sally想编辑同一个文件的结尾,这种修改不会冲突,设想修改可以正确的合并到一起,他们可以轻松的并行工作而没有太多的坏处,没有必要让他们轮流工作。
-
*锁定可能导致错误的安全状态。*假设Harry锁定和编辑一个文件A,同时Sally锁定并编辑文件B,如果A和B互相依赖,这种变化是必须同时作的,这样A和B不能正确的工作了,锁定机制对防止此类问题将无能为力―从而产生了一种处于安全状态的假相。很容易想象Harry和Sally都以为自己锁住了文件,而且从一个安全,孤立的情况开始工作,因而没有尽早发现他们不匹配的修改。
### 拷贝-修改-合并 方案
Subversion,CVS和一些版本控制系统使用*拷贝-修改-合并*模型,在这种模型里,每一个客户联系项目版本库建立一个个人*工作拷贝*―版本库中文件和目录的本地映射。用户并行工作,修改各自的工作拷贝,最终,各个私有的拷贝合并在一起,成为最终的版本,这种系统通常可以辅助合并操作,但是最终要靠人工去确定正误。
这是一个例子,Harry和Sally为同一个项目各自建立了一个工作拷贝,工作是并行的,修改了同一个文件A,Sally首先保存修改到版本库,当Harry想去提交修改的时候,版本库提示文件A已经*过期*,换句话说,A在他上次更新之后已经更改了,所以当他通过客户端请求*合并*版本库和他的工作拷贝之后,碰巧Sally的修改和他的不冲突,所以一旦他把所有的修改集成到一起,他可以将工作拷贝保存到版本库,[图2.4 “拷贝-修改-合并 方案”]( "图2.4.拷贝-修改-合并 方案")和[图2.5 “拷贝-修改-合并 方案(续)”]( "图2.5.拷贝-修改-合并 方案(续)")展示了这一过程。
**图2.4.拷贝-修改-合并 方案**
![拷贝-修改-合并 方案](https://box.kancloud.cn/2016-08-21_57b8a333c4e57.png)
**图2.5.拷贝-修改-合并 方案(续)**
![拷贝-修改-合并 方案(续)](https://box.kancloud.cn/2016-08-21_57b8a333db0f0.png)
但是如果Sally和Harry的修改*交迭*了该怎么办?这种情况叫做*冲突*,这通常不是个大问题,当Harry告诉他的客户端去合并版本库的最新修改到自己的工作拷贝时,他的文件A就会处于冲突状态:他可以看到一对冲突的修改集,并手工的选择保留一组修改。需要注意的是软件不能自动的解决冲突,只有人可以理解并作出智能的选择,一旦Harry手工的解决了冲突―也许需要与Sally讨论―它可以安全的把合并的文件保存到版本库。
拷贝-修改-合并模型感觉是有一点混乱,但在实践中,通常运行的很平稳,用户可以并行的工作,不必等待别人,当工作在同一个文件上时,也很少会有交迭发生,冲突并不频繁,处理冲突的时间远比等待解锁花费的时间少。
最后,一切都要归结到一条重要的因素:用户交流。当用户交流贫乏,语法和语义的冲突就会增加,没有系统可以强制用户完美的交流,没有系统可以检测语义上的冲突,所以没有任何证据能够承诺锁定系统可以防止冲突,实践中,锁定除了约束了生产力,并没有做什么事。
- 第1章介绍
- Subversion的历史
- Subversion的特性
- Subversion的架构
- 安装Subversion
- Subversion的组件
- 快速入门
- 第2章基本概念
- 版本模型
- Subversion实战
- 摘要
- 第3章指导教程
- 导入
- 修订版本: 号码、关键字和日期,噢,我的!
- 初始化的Checkout
- 基本的工作周期
- 检验历史
- 其他有用的命令
- 摘要
- 第4章分支与合并
- 使用分支
- 在分支间拷贝修改
- 常见用例
- 转换工作拷贝
- 标签
- 分支维护
- 摘要
- 第5章版本库管理
- 版本库的创建和配置
- 版本库维护
- 添加项目
- 摘要
- 第6章配置服务器
- 网络模型
- svnserve,一个自定义的服务器
- httpd,Apache的HTTP服务器
- 支持多种版本库访问方法
- 第7章高级主题
- 属性
- Peg和实施修订版本
- 外部定义
- 卖主分支
- 本地化
- Subversion版本库URL
- 第8章开发者信息
- 使用API
- 进入工作拷贝的管理区
- WebDAV
- 使用内存池编程
- 为Subversion做贡献
- 第9章Subversion完全参考
- svn add
- svn blame
- svn cat
- svn checkout
- svn cleanup
- svn commit
- svn copy
- svn delete
- svn diff
- svn export
- svn help
- svn import
- svn info
- svn list
- svn log
- svn merge
- svn mkdir
- svn move
- svn propdel
- svn propedit
- svn propget
- svn proplist
- svn propset
- svn resolved
- svn revert
- svn status
- svn switch
- svn update
- svnadmin
- svnadmin create
- svnadmin deltify
- svnadmin dump
- svnadmin help
- svnadmin hotcopy
- svnadmin list-dblogs
- svnadmin list-unused-dblogs
- svnadmin load
- svnadmin lstxns
- svnadmin recover
- svnadmin rmtxns
- svnadmin setlog
- svnadmin verify
- svnlook
- svnlook author
- svnlook cat
- svnlook changed
- svnlook date
- svnlook diff
- svnlook dirs-changed
- svnlook help
- svnlook history
- svnlook info
- svnlook log
- svnlook propget
- svnlook proplist
- svnlook tree
- svnlook uuid
- svnlook youngest
- svnserve
- svnversion
- mod_dav_svn Configuration Directives
- 附录A.Subversion对于CVS用户
- 目录的版本
- 更多离线操作
- 区分状态和更新
- 分支和标签
- 元数据属性
- 冲突解决
- 二进制文件和转化
- 版本化的模块
- 认证
- 转化CVS版本库到Subversion
- 附录C.WebDAV和自动版本化
- 自动版本化交互性
- Subversion和DeltaV
- 术语表