自由开源的版本管理系统整理ppt.ppt
《自由开源的版本管理系统整理ppt.ppt》由会员分享,可在线阅读,更多相关《自由开源的版本管理系统整理ppt.ppt(51页珍藏版)》请在三一文库上搜索。
1、自由、开源的版本管理系统,南京大学软件学院 2009,1,1 Subversion简介 2 版本控制的基本原理 3 Subversion基础 4 Subversion基本工作流程及基本操作 CheckOut,Commit,Update,Status 5 Subversion高级操作 Branch/Tag,Merge 6 Subversion其他操作(演示) 7 常见Subversion的GUI客户端使用(演示),内容简介,1 Subversion简介,Subversion的作用 Subversion的历史 Subversion的特性 Subversion的架构,Subversion的作用,一个
2、自由,开源的版本控制系统 一个通用系统,不是简单的一个SCM系统 以替代CVS为目标 可以管理任何类型文件,并且追踪变更 不具有某些和开发紧密结合的特性,如支持某种特定的编程语言,集成构建工具等 应用:版本管理,网络硬盘? 网址:http:/subversion.tigris.org,Subversion的历史,2000年,CollabNet公司开始寻找CVS的替代产品 2月,这个公司联系了Open Source Development with CVS的作者Karl Fogel,他同意为这个项目工作。同时,他还联系了其他几个人一起开发这个新系统 3月,Subversion开始详细设计和编码
3、2001年8月31日,Subversion第一个完整版本问世 经过1.0,1.1,1.2直到现在的1.4.3版,Subversion的特性(和CVS比较),和CVS的相似性 目录的版本化 更加好的文件版本管理(例如对文件拷贝,重命名的处理) 提交的原子性 元数据的版本化 可选的网络层 对文本文件和二进制文件一致的差异比较算法 高效的分支(branch)和标签(tag)操作 良好的可维护性,Subversion的架构,2 版本控制的基本原理,客户/服务器架构的版本控制简述 版本控制的数据共享模型 数据共享的问题 锁定-修改-解锁方案 拷贝-修改-合并方案 冲突及解决 两种方案的对比及选择 Sub
4、version的实现,客户/服务器架构的版本控制,版本库(Repository):按照一定格式存储了所有数据,包括文件和目录 经过授权的客户端可以连接到版本库,读写库中的文件 版本库和普通文件服务器的不同:版本库会记录每一次的更改,所以,客户端可以任意查询更改的历史。例如:ApplicationContext.java的1451版和1450版相比修改了什么?谁作的修改?什么时候作的修改?等等,版本控制数据共享模型,版本控制系统的核心任务:协作编辑和数据共享 基础问题:怎样允许用户共享信息,并且不会因意外而互相干扰? 数据共享问题的产生 解决办法,数据共享问题,解决方案1锁定-解锁方案,锁定-解
5、锁方案的问题,可能导致管理问题,如长期锁定文件不放 会导致不必要的顺序开发 可能导致死锁 例如Sally和Harry都需要修改plugin_mgr.c和plugin_mgr.h,两者互相关联,Sally锁定了.c文件而Harry锁定了头文件,就会进入死锁状态,解决方案2拷贝-修改-合并方案,(续图),冲突(Conflict)及解决(Resolve),冲突的产生:冲突是随着拷贝-修改-合并方案的产生而带来的问题。两个开发者使用拷贝-修改-合并方案编辑同一个文件,并且两人的修改发生了交叠时就发生了冲突 冲突的解决:当冲突发生时,开发者会看到一对冲突的修改结果,通常情况下,必须让引起冲突的两个人商议
6、之后,手动选择保留一组更改。在这里,版本控制系统只能提示冲突的发生而无法给出解决建议 冲突的预防:增加开发者的交流可以最大限度减少冲突的发生,但是不可能杜绝冲突 后面可以看到冲突的具体例子以及解决办法,两种方案的对比及选择,虽然锁定-解锁方案有很多的弊端,但在一些情况下仍然是必须的;虽然拷贝-修改-合并模型能解决大多数问题,但它也不是万能的 比较:文本文件和二进制文件的特点 选择:拷贝-合并模型假定文件是可以通过上下文合并的。通常情况下,文本文件(例如源代码以及用纯文本,HTML,TeX等格式保存的文档)因为其内部结构直观可知,容易理解上下文,所以用拷贝合并方案较好。而二进制文件(例如用Mic
7、rosoft Word格式,PDF等格式保存的文档及图片,声音,可执行文件,库等)内部结构复杂,且不容易理解更改处的上下文,采用锁定-解锁方案较好,Subversion的实现,Subversion主要采用拷贝-修改-合并模型,配合锁定-解锁模型管理数据的共享,3 Subversion基础,基本概念 工作拷贝(Working Copy) 修订版本(Revision) 文件状态 混合修订版本的工作拷贝,工作拷贝(Working Copy),工作拷贝是本地机器的一个普通的目录。这个目录的内容是版本库中某个目录的拷贝。工作拷贝是私有工作区,可以任意编辑里面的文件并且发布更改 通常,一个工作拷贝对应于版
8、本库的一个子目录,日常的开发是针对工作拷贝进行的 工作拷贝里面还有一些由Subversion创建和维护的额外文件,用于命令的协助执行,所以它们又叫工作拷贝管理目录。通常,它们都保存在工作拷贝目录及子目录下的.svn目录(隐藏)中,凭借这个目录中保存的信息,Subversion可以识别哪一个文件被修改了,哪一个文件已经过时了,等等,修订版本(Revision),SVN的提交(Commit)操作是把工作拷贝的更改发布到版本库的一个原子操作。每当一次提交完成后,版本库的文件系统就进入了一个新的状态,叫做一次修订(Revision),每一次修订都会赋予一个独一无二的版本号,一般是从0开始的递增自然数,
9、一个比一个大 初始修订版本是0,这只是一个空目录,没有任何内容。随着每次的提交,版本库里仿佛就多了一个当前内容的“快照”。在版本库中,最新的一个修订版本称为HEAD,修订版本(图示),(HEAD),文件状态,对于工作拷贝的每一个文件,SVN在管理目录(.svn)记录两项关键的信息 该文件作为基准的修订版本(叫做文件的工作修订版本) 该文件最后更新的时间戳 根据以上两项关键信息,通过和版本库通讯,SVN可以得到工作拷贝中一个文件的状态,它有下面几种可能 未修改,并且版本库也未修改(Up-to-date状态) 已修改,但是版本库没有修改(Modified状态) 未修改,但是版本库已经修改 已修改,
10、并且版本库也已修改(需要合并) 可以用svn status命令查看文件状态,混合修订版本的工作拷贝,很灵活,但是比较难理解的一个特性 混合修订版的工作拷贝:为了灵活,允许一个工作拷贝中存在多个修订版本的文件 SVN特性:修订版本号的全局性。如果某文件的修订号为N,并不意味这这个文件被提交了N次(甚至有可能这个文件只修改过1次),而意味着整个版本库被提交了N次 当一次Checkout或者(整个工作拷贝的)Update操作完成后,工作拷贝中所有文件都会被更新到同一个版本号 两个操作可能引起混合版本的情况:提交和部分更新,混合修订版本的工作拷贝(续),提交会引起混合修订版本的情况 SVN的原则:一个
11、PUSH的动作不会导致被PUSH,或者反之。换句话说,提交某个修改的过程不会导致工作拷贝被修改。在SVN中,更新和提交是分开的 当提交修改时,被提交修改的文件版本号将递增,但是工作拷贝中的其他文件仍然保持原有版本号,于是就形成了混合修订版本的格局,混合修订版本的工作拷贝(续),很显然,(部分)更新也可能会引起这种情况 部分更新是指对工作拷贝中某个文件或者子目录的更新操作(不限于更新到HEAD) 很灵活的一个特性,混合修订版本的工作拷贝(续),混合修订版本是一种正常的情况 同时,混合修订版本很有用 例如,可以用来追溯Bug的源头,或者确定某个特性在某个历史版本中是否具有 会影响某些命令,如Log
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 自由 版本 管理 系统 整理 ppt
链接地址:https://www.31doc.com/p-2325601.html