版本控制基本概念之版本模型

简介:

本文摘自TortoiseSVN的使用帮助,对版本控制中的版本模型有比较好的解释,举得例子也很直观,非常好理解。

2.2. 版本模型

所有的版本控制系统都需要解决这样一个基础问题: 怎样让系统允许用户共享信息,而不会让他们因意外而互相干扰?版本库里意外覆盖别人的更改非常的容易。

2.2.1. 文件共享的问题

考虑这个情景,我们有两个共同工作者,Harry 和 Sally,他们想同时编辑版本库里的同一个文件,如果首先 Harry 保存它的修改,过了一会,Sally 可能凑巧用自己的版本覆盖了这些文件,Harry 的更改不会永远消失(因为系统记录了每次修改),Harry 所有的修改不会出现在 Sally 的文件中,所以 Harry 的工作还是丢失了—至少是从最新的版本中丢失了—而且是意外的,这就是我们要明确避免的情况!

图 2.2. 需要避免的问题

image

2.2.2. 锁定-修改-解锁 方案

许多版本控系统使用 锁定-修改-解锁 模型来解决这个问题,这是一个简单的解决方案。在这种系统中,在同一时间版本库只允许一个用户修改一个文件。首先,Barry 必须在修改前 锁定 该文件。锁定文件有点像从图书馆结束; 如果 Harry 锁定了一个文件,那么 Sally 就修改该文件。如果她试图锁定该文件,版本库会拒绝这个请求。她只能读取这个文件,并等待 Harry 结束修改并释放文件锁。在 Harry 解锁文件后,他的任务就完成了,现在 Sally 可以接手工作 - 锁定并编辑文件。

图 2.3. 锁定-修改-解锁 方案

image

锁定-修改-解锁模型有一点问题就是限制太多,经常会成为用户的障碍:

  • 锁定可能导致管理问题。有时候 Harry 会锁住文件然后忘了此事,这就是说 Sally 一直等待解锁来编辑这些文件,她在这里僵住了。然后 Harry 去旅行了,现在 Sally 只好去找管理员放开锁,这种情况会导致不必要的耽搁和时间浪费。

  • 锁定可能导致不必要的线性化开发。如果 Harry 编辑一个文件的开始,Sally 想编辑同一个文件的结尾,这种修改不会冲突,设想修改可以正确的合并到一起,他们可以轻松的并行工作而没有太多的坏处,没有必要让他们轮流工作。

  • 锁定可能导致错误的安全状态。假设 Harry 锁定和编辑一个文件 A,同时 Sally 锁定并编辑文件 B,如果 A 和 B 互相依赖,这种变化是必须同时作的,这样 A 和 B 不?苷返墓ぷ髁耍ɑ贫苑乐勾死辔侍饨弈芪Α佣艘恢执τ诎踩刺募傧唷:苋菀紫胂? Harry 和 Sally 都以为自己锁住了文件,而且从一个安全,孤立的情况开始工作,因而没有尽早发现他们不匹配的修改。

2.2.3. 复制-修改-合并 方案

Subversion,CVS 和一些版本控制系统使用 复制-修改-合并 模型,在这种模型里,每一个客户读取项目版本库建立一个私有工作副本 - 版本库中文件和目录的本地映射。用户并行工作,修改各自的工作副本,最终,各个私有的复制合并在一起,成为最终的版本,这种系统通常可以辅助合并操作,但是最终要靠人工去确定正误。

这儿有一个例子。比如说 Harry 和 Sally 参加同一个项目每人都有各自的工作副本,从同一个版本库复制出来的。他们同时工作,在自己的副本中修改同一个文件 A。Sally 先将她的更改保存到版本库中。 稍后,当 Harry 尝试提交他的更改时,版本库提示他的文件 A 已经过时。换句话说,自从他上次复制文件后,无论如何版本库中的文件 A 已经被修改了。所以 Harry 要用客户端程序将版本库中文件 A 的新更改 合并 到他的工作副本中。碰巧的是 Sally 的更改和他的不重合; 所以一旦他整合了两人的更改,他就可以把他的工作副本复制回版本库。

图 2.4. 复制-修改-合并 方案

image

图 2.5. 复制-修改-合并 方案(续)

image

但是如果 Sally 和 Harry 的修改重叠了该怎么办?这种情况叫做冲突,这通常不是个大问题,当 Harry 告诉他的客户端去合并版本库的最新修改到自己的工作副本时,他的文件 A 就会处于冲突状态: 他可以看到一对冲突的修改集,并手工的选择保留一组修改。需要注意的是软件不能自动的解决冲突,只有人可以理解并作出智能的选择,一旦 Harry 手工的解决了冲突(也许需要与 Sally 讨论),他就可以安全的把合并的文件保存到版本库。

复制-修改-合并模型感觉是有一点混乱,但在实践中,通常运行的很平稳,用户可以并行的工作,不必等待别人,当工作在同一个文件上时,也很少会有重叠发生,冲突并不频繁,处理冲突的时间远比等待解锁花费的时间少。

最后,一切都要归结到一条重要的因素: 用户交流。当用户交流贫乏,语法和语义的冲突就会增加,没有系统可以强制用户完美的交流,没有系统可以检测语义上的冲突,所以没有任何证据能够承诺锁定系统可以防止冲突,实践中,锁定除了约束了生产力,并没有做什么事。

有一种情况下锁定-修改-解锁模型会更好,也就是你有不可合并的文件,例如你的版本库包含了图片,两个人同时编辑这个文件,没有办法将这两个修改合并,Harry 或 Sally 会丢失他们的修改。

2.2.4. Subversion 怎么做?

Subversion 缺省使用复制-修改-合并模型,大多数情况下可以满足你的需求。然而,Subversion 1.2 后还是支持锁定,如果你有不可合并的文件,或者你只是想实行强制管理策略,Subversion 仍然会提供你需要的特性。


本文转自emouse博客园博客,原文链接:http://www.cnblogs.com/emouse/archive/2012/06/03/2532692.html,如需转载请自行联系原作者

相关文章
|
存储 XML 数据可视化
通用仓库元模型概述
通用仓库元模型(Common Warehouse metamodel,CWM)指定了可用于在分布式异构环境中的仓库工具、仓库平台和仓库元数据存储库之间轻松交换仓库和商业智能元数据的接口。
657 0
通用仓库元模型概述
|
6月前
|
Cloud Native Unix Go
开源协议对比:局限性、应注意事项与详细对比
开源协议对比:局限性、应注意事项与详细对比
256 0
|
6月前
|
存储 Linux 开发工具
Git简介与工作原理:了解Git的基本概念、版本控制系统和分布式版本控制的工作原理
Git简介与工作原理:了解Git的基本概念、版本控制系统和分布式版本控制的工作原理
209 0
|
7月前
|
开发工具 数据安全/隐私保护 git
团队开发注意事项
团队开发注意事项
|
11月前
|
JSON 测试技术 数据格式
2022/9/5开始第三版接口自动化(yaml用例)测试框架(记录搭建过程)(这个废弃了)
2022/9/5开始第三版接口自动化(yaml用例)测试框架(记录搭建过程)(这个废弃了)
|
11月前
|
机器学习/深度学习 人工智能 算法
纠错数据标注,只需一行代码:开源项目Cleanlab发布了2.0版本
纠错数据标注,只需一行代码:开源项目Cleanlab发布了2.0版本
133 0
|
11月前
|
前端开发 测试技术 持续交付
基于 Git 的开发工作流——主干开发特性总结
基于 Git 的开发工作流——主干开发特性总结
185 0
|
存储 机器学习/深度学习 缓存
DVC 使用指南:常用术语
依赖(Dependency):记录在 Stage 的deps部分(在 dvc.yaml 中)或 .dvc 文件中的文件或目录(可能由DVC跟踪)。请参阅 dvc run。当任何依赖项发生变化时,Stage 就会失效(被认为已过时)。
|
存储 机器学习/深度学习 缓存
快速入门DVC(三):数据与模型版本管理
数据和模型版本控制是 DVC 的基础层用于管理大型文件、数据集和机器学习模型。使用常规的 Git 工作流程,但不要在 Git 库中存储大文件。 大数据文件单独存储,来实现高效共享。想象一下,让 Git 以与处理小代码文件相同的性能来处理任意大的文件和目录,该有多酷?例
|
存储 机器学习/深度学习 缓存
DVC 使用案例(一):数据与模型版本管理
数据科学团队常常面临着数据和机器学习模型进行版本化的数据管理问题。我们应该如何一起跟踪数据、源代码和ML模型中的变化?组织和存储这些文件和目录变更的最佳方式是什么?