软件配置管理zhjr版本控制PPT课件

QQ zhjr 即1211460305 电话授课 张金荣Email zhjr2000 zhjr 软件配置管理 2 版本控制 版本控制是所有配置管理系统的核心功能 配置管理系统的其它功能大都建立在版本控制功能之上 版本控制的对象是软件开发过程中涉及的所有文件系统对象 包括文件 目录和链接 可定版本的文件包括源代码 可执行文件 位图文件 需求文档 设计说明 测试计划 和一些ASCII和非ASCII文件等等 目录的版本记录了目录的变化历史 包括新文件的建立 新的子目录的创建 已有文件或子目录的重新命名 已有文件或子目录的删除等等 3 版本控制的目的在于对软件开发进程中文件或目录的发展过程提供有效的追踪手段 保证在需要时可回到旧的版本 避免文件的丢失 修改的丢失和相互覆盖 通过对版本库的访问控制避免未经授权的访问和修改 达到有效保护企业软件资产和知识产权的目的 另外版本控制是实现团队并行开发 提高开发效率的基础 4 源文件是软件最重要的组成单元 对源文件的管理也成为重要一环 源文件标识 文件名和版本版本定义 是指某一特定对象的具体实例的潜在存在 版本记录了配置项的演化过程 1 版本 5 看看我的曾经的文件 6 7 即使只有只有一个程序员 8 程序员间随意传递源代码 9 2 版本控制系统 版本控制系统 VersionControlSystem VCS 可以帮助我们记录和跟踪项目中各文件内容的修改变化 它最简单的 手工的实现形式是 复制文件以备份 在备份文件的文件名中添加上时间和日期 然而 为了效率起见 我们希望这类操作在某种程度上是自动的 这是我们需要版本控制工具的原因 这类工具能够自动地备份和跟踪项目中所有代码的修改 10 3 版本库 版本库 Repository 是版本控制系统用来存储所有历史数据的地方 大多数版本控制系统在版本库中存储各个文件的当前状态 历史修改时间 谁做的修改 以及修改的原因 11 版本库是Subversion的核心部分 是数据的中央仓库 版本库以典型的文件和目录结构形式文件系统树来保存信息 任意数量的客户端连接到Subversion版本库 读取 修改这些文件 客户端通过写数据将信息分享给其他人 通过读取数据获取别人共享的信息 在Subversion没有 项目 的概念 Subversion的版本库只是一个虚拟的版本化文件系统 可以存放你想要存放的任何文件 有些管理员喜欢为每个项目建立一个独立的版本库而另外一些管理员则喜欢将多个项目存放到同一个版本库的不同目录里 不论是哪一种方式 版本库都只是负责管理文件和目录 而 项目 则是人为指定的概念 因此 谈到项目这个词 我们只不过是在谈论版本库中的某些特定目录 或者是一组目录 3 1Subversion版本库 12 一个典型的客户 服务器系统Subversion中 WhatShouldYouStoreinyourrepository 13 3 2版本库存储的内容 对此问题的简短回答 所有内容 稍微复杂一些的回答是 存储项目开发所必需的所有内容 这使得程序员能够修改代码 编译构建 使项目前进 显然 首先要存储的是项目源代码 否则 既无法修复缺陷也无法继续开发新功能 14 大多数项目都有一些构建文件 常见的有 Makefile Rakefile及Ant的build xml 这些文件都要放入版本库 以方便源代码编译构建 版本库中其他常见存储内容还有 配置文件样例 各类文档 程序使用的图片 当然还有单元测试脚本 要判断哪些内容应该纳入版本控制很简单 自己想一下 如果没有某样东西 我能在这个项目中工作吗 如果答案是否定的 那么这样东西就应当纳入版本控制 但凡事皆有例外 项目中使用的开发工具 通常不用放到版本控制中去 比如 Ant的 build xml 应该放到版本控制中 但Ant工具本身不需要 这个例外并不是这么严格的 可以考虑把Ant JUnit等工具都放入版本库中 以保证大家都使用相同版本的工具 当然 最好把它们与项目本身的内容分开存放 15 3 3和一般的文件服务器的区别 Subversion听起来和一般的文件服务器没什么不同 事实上 Subversion的版本库的确是一种文件服务器 但不是 一般 的文件服务器 Subversion版本库的特别之处在于 它会记录每一次改变 每个文件的改变 甚至是目录树本身的改变 例如文件和目录的添加 删除和重新组织 一般情况下 客户端从版本库中获取的数据是文件系统树中的最新数据 但是客户端也具备查看文件系统树以前任何一个状态的能力 举个例子 客户端有时会对一些历史性问题感兴趣 比如 上星期三时的目录结构是什么样的 或者 谁最后一个修改了这个文件 都修改了什么 这些都是版本控制系统的核心问题 设计用来记录和跟踪数据变化的系统 16 3 4集中式和分布式版本控制 集中式版本库 CentralizedRepository 模式 在这种模式中 所有的程序员都会把他们的改动提交到服务器上的一个公共版本库中 具体来说 每一个程序员在本地有一个工作目录树 其内容是该版本库中最新的代码 当他们在工作目录树中完成代码修改后 就把改动提交回该版本库中 分布式版本控制系统 Distributedversioncontrolsystem DVCS 也是这样 它的主要目标仍然是帮助记录和跟踪项目中所做的修改 而它与传统版本控制系统的区别在于 开发人员相互同步修改内容的方式不同 17 版本控制系统就好比是银行保险箱 而它所保存的历史信息就好比对账单 每当存入一笔存款时 或者用版本控制系统的行话来说 每当进行一次提交 Commit 的时候 版本控制系统就会在 对账单 上添加一个条目 并且把提交的内容保存在版本库里 集中式版本控制系统就好比是程序员们共用一个保险箱 而分布式版本控制系统就好像是每个程序员都有他自己的个人保险箱 那么 在分布式版本控制系统中 程序员之间如何传递各自的修改 如何同步呢 程序员还是将修改上传到项目主版本库 这有两种实现方法 可以通过 推入 Push 操作直接把修改上传到主版本库 也可以生成包含少量修改的补丁包 把补丁包提交给项目维护人员 再由项目维护人员更新主版本库 18 4 版本模型 版本控制系统的核心任务是实现协作编辑和数据共享不同的系统使用不同的策略实现这个目的 我们有许多理由要去理解这些策略的区别 首先 如果你遇到了其他类似Subversion的系统 可以帮助你比较现有的版本控制系统 此外 可以帮助你更有效的使用Subversion 因为Subversion本身支持不同的工作方式 19 版本库里意外覆盖别人的更改非常的容易 所有的版本控制系统都需要解决这样一个基础问题 怎样让系统允许用户共享信息 而不会让他们因意外而互相干扰 20 以这个工作模型为例 星形结构公共存储区 21 共享 覆盖 问题的出现 我们有两个共同工作者 Harry和Sally 他们想同时编辑版本库里的同一个文件 如果首先Harry保存它的修改 过了一会 Sally可能凑巧用自己的版本覆盖了这些文件 Harry的更改不会永远消失 因为系统记录了每次修改 但Harry所有的修改不会出现在Sally新版本的文件中 所以Harry的工作还是丢失了 至少是从最新的版本中丢失了 而且可能是意外的 这就是我们要明确避免的情况 22 锁定 修改 解锁方案 在这样的模型里 在一个时间段里版本库的一个文件只允许被一个人修改 23 锁定 修改 解锁模型有一点问题就是限制太多 经常会成为用户的障碍 锁定可能导致管理问题 有时候Harry会锁住文件然后忘了此事 这就是说Sally一直等待解锁来编辑这些文件 她在这里僵住了 然后Harry去旅行了 现在Sally只好去找管理员放开锁 这种情况会导致不必要的耽搁和时间浪费 锁定可能导致不必要的线性化开发 如果Harry编辑一个文件的开始 Sally想编辑同一个文件的结尾 这种修改不会冲突 设想修改可以正确的合并到一起 他们可以轻松的并行工作而没有太多的坏处 没有必要让他们轮流工作 锁定可能导致错误的安全状态 假设Harry锁定和编辑一个文件A 同时Sally锁定并编辑文件B 如果A和B互相依赖 这种变化是必须同时作的 这样A和B不能正确的工作了 锁定机制对防止此类问题将无能为力 从而产生了一种处于安全状态的假相 很容易想象Harry和Sally都以为自己锁住了文件 而且从一个安全 孤立的情况开始工作 因而没有尽早发现他们不匹配的修改 锁定经常成为真正交流的替代品 24 拷贝 修改 合并方案 Subversion CVS和一些版本控制系统使用拷贝 修改 合并模型 Harry和Sally为同一个项目各自建立了一个工作拷贝 工作是并行的 修改了同一个文件A Sally首先保存修改到版本库 当Harry想去提交修改的时候 版本库提示文件A已经过期 25 换句话说 A在他上次更新之后已经更改了 所以当他通过客户端请求合并版本库和他的工作拷贝之后 碰巧Sally的修改和他的不冲突 所以一旦他把所有的修改集成到一起 他可以将工作拷贝保存到版本库 26 冲突 但是如果Sally和Harry的修改交迭了该怎么办 这种情况叫做冲突 这通常不是个大问题 当Harry告诉他的客户端去合并版本库的最新修改到自己的工作拷贝时 他的文件A就会处于冲突状态 他可以看到一对冲突的修改集 并手工的选择保留一组修改 需要注意的是软件不能自动的解决冲突 只有人可以理解并作出智能的选择 一旦Harry手工的解决了冲突 也许需要与Sally讨论 它可以安全的把合并的文件保存到版本库 拷贝 修改 合并模型感觉有一点混乱 但在实践中 通常运行的很平稳 用户可以并行的工作 不必等待别人 当工作在同一个文件上时 也很少会有交迭发生 冲突并不频繁 处理冲突的时间远比等待解锁花费的时间少 27 什么时候使用锁定解锁 锁定 修改 解锁模型被认为不利于协作 但有时候锁定会更好 拷贝 修改 合并模型假定文件是可以根据上下文合并的 就是版本库的文件主要是以行为基础的文本文件 例如程序源代码 但对于二进制格式 例如艺术品或声音 在这种情况下 十分有必要让用户轮流修改文件 如果没有线性的访问 有些人的许多工作就最终要被放弃 尽管Subversion一直主要是一个拷贝 修改 合并系统 但是它也意识到了需要锁定一些文件 并且提供这种锁定机制 28 5 工作空间 工作目录树 工作空间 即工作目录树 WorkingTree 也就是程序员进行程序开发的地方 工作目录树是版本库的一个 断面视图 它包括了开发该项目所需要的全部文件 包括源代码文件 构建文件 单元测试文件等 一些版本控制系统 Subversion 把工作目录树称为工作拷贝 WorkingCopy 在Subversion等传统的版本控制工具中 工作目录在本地 版本库在服务器上 而Git中并非如此 29 6 按任务单元组织工作 任务单元 task 又称活动 activity 是指一个明确的工作单元 可以和其他工作单元分开 带有明确的目的 30 从实际看 任务单元对应一个或多个文件上的一处或多处变动 这些变动组合在一起 称为一个变更集 changeset 或变更包 changepackage 31 任务单元累加 直到软件完成 32 从创建到提交 33 7产品的整体版本 文件版本组成整体版本保存安装包 34 开发 测试 发布 35 8SVN版本实践 本节内容关于subversion的版本问题描述 36 8 1SVN的URL 正如我们在整本书里描述的 Subversion使用URL来识别Subversion版本库中的版本化资源 通常情况下 这些URL使用标准的语法 允许服务器名称和端口作为URL的一部分 37 svncheckout 9834 repos svncheckoutfile path to repos svncheckoutfile localhost path to repos 38 同样 在Windows平台下使用file 模式时需要使用一个非正式的 标准 语法来访问本机上不在同一个磁盘分区中的版本库 下面的任意一个URL路径语法都可以工作 其中的X表示版本库所在的磁盘分区 C svncheckoutfile X path to reposC svncheckout file X path to repos 在第二个语法里 你需要使用引号包含整个URL 这样竖线字符才不会被解释为管道 当然 也要注意URL使用普通的斜线而不是Windows本地 不是URL 的反斜线 39 8 2Subversion工作拷贝 一个Subversion工作拷贝是你本地机器上的一个普通目录 保存着一些文件 你可以任意的编辑文件 而且如果是源代码文件 你可以像平常一样编译 你的工作拷贝是你的私有工作区 在你明确的做了特定操作之前 Subversion不会把你的修改与其他人的合并 也不会把你的修改展示给别人 你甚至可以拥有同一个项目的多个工作拷贝 当你在工作拷贝作了一些修改并且确认它们工作正常之后 Subversion提供了一个命令可以 发布 你的修改给项目中的其他人 通过写到版本库 如果别人发布了各自的修改 Subversion提供了手段可以把这些修改与你的工作目录进行合并 通过读取版本库 工作副本也包括一些由Subversion创建并维护的额外文件 用来协助执行命令 通常情况下 你的工作副本的每个文件夹都有一个以 svn为名的文件夹 也被叫做工作副本的管理目录 这个目录里的文件能够帮助Subversion识别哪些文件做过修改 哪些文件相对于别人的工作已经过期 40 一个典型的Subversion的版本库经常包含许多项目的文件 或者说源代码 通常每一个项目都是版本库的子目录 在这种布局下 一个用户的工作拷贝往往对应版本库的的一个子目录 举一个例子 你的版本库包含两个软件项目 paint和calc 每个项目在它们各自的顶级子目录下为了得到一个工作拷贝 你必须检出 checkout 版本库的一个子树 41 你现在有了一个 calc的个人拷贝 有一个附加的目录 svn 保存着前面提及的Subversion需要的额外信息 假定你修改了button c 因为 svn目录记录着文件的修改日期和原始内容 Subversion可以告诉你已经修改了文件 然而 在你明确告诉它之前 Subversion不会将你的改变公开 将改变公开的操作被叫做提交 committing 或者是checkingin 修改到版本库 将你的修改发布给别人 你可以使用Subversion的提交 commit 命令要使项目最新 可以要求Subversion更新工作备份 通过使用更新 update 命令 将结合你和所有其他人在她上次更新之后的改变到她的工作拷贝 不必指定要更新的文件 subversion利用 svn以及版本库的进一步信息决定哪些文件需要更新 42 8 3修订版本 一个svncommit操作可以作为一个原子事务操作发布任意数量文件和目录的修改 在你的工作拷贝里 你可以改变文件内容 删除 改名以及拷贝文件和目录 然后作为一个原子事务一起提交 原子事务 的意思是 要么所有的改变发生 要么都不发生 Subversion努力保持原子性以应对程序错误 系统错误 网络问题和其他用户行为 每当版本库接受了一个提交 文件系统进入了一个新的状态 叫做一次修订 revision 每一个修订版本被赋予一个独一无二的自然数 一个比一个大 初始修订号是0 只创建了一个空目录 没有任何内容 43 描述版本库 想象有一组修订号 从0开始 从左到右 每一个修订号有一个目录树挂在它下面 每一个树好像是一次提交后的版本库 快照 44 不像其他版本控制系统 Subversion的修订号是针对整个目录树的 而不是单个文件 每一个修订号代表了一次提交后版本库整个目录树的特定状态 另一种理解是修订号N代表版本库已经经过了N次提交 当Subversion用户讨论 foo c的修订号5 时 他们的实际意思是 在修订号5时的foo c 需要注意的是 一个文件的修订版本N和M并不必有所不同 许多其它版本控制系统使用每文件一个修订号的策略 所以会感觉这些概念有点不一样 45 需要特别注意的是 工作拷贝并不一定对应版本库中的单个修订版本 他们可能包含多个修订版本的文件 举个例子 你从版本库检出一个工作拷贝 最近的修订号是4 calc Makefile 4integer c 4button c 4此刻 工作目录与版本库的修订版本4完全对应 然而 你修改了button c并且提交之后 假设没有别的提交出现 你的提交会在版本库建立修订版本5 你的工作拷贝会是这个样子的 calc Makefile 4integer c 4button c 5 46 假设此刻 Sally提交了对integer c的修改 建立修订版本6 如果你使用svnupdate来更新你的工作拷贝 你会看到 calc Makefile 6integer c 6button c 6Sally对integer c的改变会出现在你的工作拷贝 你对button c的改变还在