自由开源的版本管理系统PPT文档共53页

修订版本（Revision）
• SVN的提交（Commit）操作是把工作拷贝 的更改发布到版本库的一个原子操作。 每当一次提交完成后，版本库的文件系 统就进入了一个新的状态，叫做一次修 订（Revision），每一次修订都会赋予一 个独一无二的版本号，一般是从0开始的 递增自然数，一个比一个大
• 初始修订版本是0，这只是一个空目录， 没有任何内容。随着每次的提交，版本 库里仿佛就多了一个当前内容的“快 照”。在版本库中，最新的一个修订版 本称为HEAD
Subversion的实现
• Subversion主要采用拷贝-修改-合并 模型，配合锁定-解锁模型管理数据 的共享
3 Subversion基础
• 基本概念
– 工作拷贝（Working Copy） – 修订版本（Revision）
• 文件状态 • 混合修订版本的工作拷贝
工作拷贝（Working Copy）
修订版本（图示）
(HEAD)
文件状态
• 对于工作拷贝的每一个文件，SVN在管理目录 （.svn)记录两项关键的信息
– 该文件作为基准的修订版本（叫做文件的工作修订版 本）
– 该文件最后更新的时间戳
• 根据以上两项关键信息，通过和版本库通讯， SVN可以得到工作拷贝中一个文件的状态，它有 下面几种可能
– 例如Sally和Harry都需要修改 plugin_mgr.c和plugin_mgr.h，两者互相 关联，Sally锁定了.c文件而Harry锁定了 头文件，就会进入死锁状态
解决方案2——拷贝-修改-合 并方案
（续图……）
冲突（Conflict）及解决 （Resolve）
• 冲突的产生：冲突是随着拷贝-修改-合并方案的 产生而带来的问题。两个开发者使用拷贝-修改合并方案编辑同一个文件，并且两人的修改发 生了交叠时就发生了冲突
Subversion的架构
2 版本控制的基本原理
• 客户/服务器架构的版本控制简述 • 版本控制的数据共享模型
– 数据共享的问题 – 锁定-修改-解锁方案 – 拷贝-修改-合并方案 – 冲突及解决 – 两种方案的对比及选择
• Subversion的实现
客户/服务器架构的版本控 制
• 版本库（Repository）：按照一定格 式存储了所有数据，包括文件和目 录
自由开源的版本管理系统
自由、开源的版本管理系统
南京大学软件学院 2009
2
Subversion的特性（和CVS比较）
• 和CVS的相似性 • 目录的版本化 • 更加好的文件版本管理（例如对文件拷贝，重
命名的处理） • 提交的原子性 • 元数据的版本化 • 可选的网络层 • 对文本文件和二进制文件一致的差异比较算法 • 高效的分支（branch）和标签（tag）操作 • 良好的可维护性
工作拷贝中存在多个修订版本的文件 • SVN特性：修订版本号的全局性。如果某文件的
修订号为N，并不意味这这个文件被提交了N次 （甚至有可能这个文件只修改过1次），而意味 着整个版本库被提交了N次 • 当一次Checkout或者（整个工作拷贝的）Update 操作完成后，工作拷贝中所有文件都会被更新 到同一个版本号 • 两个操作可能引起混合版本的情况：提交和部 分更新
• 工作拷贝是本地机器的一个普通的目录。这个 目录的内容是版本库中某个目录的拷贝。工作 拷贝是私有工作区，可以任意编辑里面的文件 并且发布更改
• 通常，一个工作拷贝对应于版本库的一个子目 录，日常的开发是针对工作拷贝进行的
• 工作拷贝里面还有一些由Subversion创建和维护 的额外文件，用于命令的协助执行，所以它们 又叫工作拷贝管理目录。通常，它们都保存在 工作拷贝目录及子目录下的.svn目录（隐藏）中， 凭借这个目录中保存的信息，Subversion可以识 别哪一个文件被修改了，哪一个文件已经过时 了，等等
– 未修改，并且版本库也未修改（Up-to-date状态) – 已修改，但是版本库没有修改（Modified状态） – 未修改，但是版本库已经修改 – 已修改，并且版本库也已修改（需要合并）
• 可以用svn status命令查 很灵活，但是比较难理解的一个特性 • 混合修订版的工作拷贝：为了灵活，允许一个
• 冲突的解决：当冲突发生时，开发者会看到一 对冲突的修改结果，通常情况下，必须让引起 冲突的两个人商议之后，手动选择保留一组更 改。在这里，版本控制系统只能提示冲突的发 生而无法给出解决建议
• 冲突的预防：增加开发者的交流可以最大限度 减少冲突的发生，但是不可能杜绝冲突
• 后面可以看到冲突的具体例子以及解决办法
• 版本控制系统的核心任务：协作编 辑和数据共享
• 基础问题：怎样允许用户共享信息， 并且不会因意外而互相干扰？
• 数据共享问题的产生 • 解决办法
数据共享问题
解决方案1——锁定-解锁方案
锁定-解锁方案的问题
• 可能导致管理问题，如长期锁定文 件不放
• 会导致不必要的顺序开发 • 可能导致死锁
• 经过授权的客户端可以连接到版本 库，读写库中的文件
• 版本库和普通文件服务器的不同： 版本库会记录每一次的更改，所以， 客户端可以任意查询更改的历史。 例如：ApplicationContext.java的1451 版和1450版相比修改了什么？谁作 的修改？什么时候作的修改？等等
版本控制数据共享模型
两种方案的对比及选择
• 虽然锁定-解锁方案有很多的弊端，但在一些情 况下仍然是必须的；虽然拷贝-修改-合并模型能 解决大多数问题，但它也不是万能的
• 比较：文本文件和二进制文件的特点 • 选择：拷贝-合并模型假定文件是可以通过上下
文合并的。通常情况下，文本文件（例如源代 码以及用纯文本，HTML，TeX等格式保存的文档） 因为其内部结构直观可知，容易理解上下文， 所以用拷贝—合并方案较好。而二进制文件（例 如用Microsoft Word格式，PDF等格式保存的文 档及图片，声音，可执行文件，库等）内部结 构复杂，且不容易理解更改处的上下文，采用 锁定-解锁方案较好