CVS与SVN的比较V11.docx
《CVS与SVN的比较V11.docx》由会员分享，可在线阅读，更多相关《CVS与SVN的比较V11.docx（10页珍藏版）》请在冰豆网上搜索。
CVS与SVN的比较V11
CVS与SVN的比较
版本：
1.1
发布日期：
2010-11-30
实施日期：
2010-11-30
修改日期：
2011-2-16
修订记录
日期
版次
描述
作者
审核
批准
2010-11-30
1.0
初版发布
孙管理
2011-2-16
1.1
添加比较表
孙管理
目录
修订记录2
1.什么是CVS4
2.SVN与CVS的比较6
1.全局性的版本编号6
2.目录的版本控制6
3.原子性提交6
4.差异化的二进制文件处理7
5.双向的差异化－压缩网络传输8
6.高效、快捷创建分支和基线8
7.更好的冲突标识与处理8
8.更多本地/离线操作9
9.元数据管理9
10.集成ApacheWebServer，提供更多的特性9
11.支持WebDAV10
3.CVS与SVN比较表10
1.什么是CVS
CVS是并发版本系统（ConcurrentVersionsSystem）的意思，主流的开放源码网络透明的版本控制系
统。
CVS对于从个人开发者到大型，分布团队都是有用的：
它的客户机/服务器存取方法使得开发者可以从任何因特网的接入点存取最新的代码。
它的无限制的版本管理检出（checkout：
注1）的模式避免了通常的因为排它检出模式而引起的人工冲突。
它的客户端工具可以在绝大多数的平台上使用。
CVS被应用于流行的开放源码工程中，象Mozilla，GIMP，XEmacs，KDE，和GNOME等。
那么它到底怎么样？
你可能会说，它非常棒，但是对于"我"来说它能做什么？
首先，基本的：
一个版本控制系统保持了对一
系列文件所作改变的历史记录。
对于一个开发者来说，那就意味着在你对一个程序所进行开发的整个期间，
能够跟踪对其所作的所有改动的痕迹。
对你来说，有没有出现过由于在命令行上按错键而导致一天的工作都
白费的情况呢？
版本控制系统给了你一个安全的网络。
版本控制系统对任何人都有用，真的。
（毕竟，谁不愿意使用一个安全的网络呢？
）但是它们经常被软件
开发团队使用。
在团队中工作的开发者需要能够调整他们的各自的修改；一个集中式版本控制系统允许那样
做。
代码集中的配置
个人开发者希望一个版本控制系统的安全网络能够运行在他们的本地的一台机器上。
然而，开发团队需
要一个集中的服务器，所有的成员可以将服务器作为仓库来访问他们的代码。
在一个办公室中，没有问题--
只是将仓库连到本地网络上的一台服务器上就行了。
对于开放源码项目...噢，还是没有问题，这要感谢因特
网。
CVS内建了客户机/服务器存取方法，所以任何一个可以连到因特网上的开发者都可以存取在一台CVS服务
器上的文件。
调整代码
在传统的版本控制系统中，一个开发者检出一个文件，修改它，然后将其登记回去。
检出文件的开发者
拥有对这个文件修改的排它权。
没有其它的开发者可以检出这个文件--并且只有检出那个文件的开发者可
以登记（checkin：
注2）所做的修改。
（当然对于管理员有很多方法可以超越这个限制。
）
想一下排它的检出可能会如何工作：
Bob的兄弟检出foo.java以便加入注释，写好代码后他什么也没做。
然后他去吃午饭了。
Bob吃完午饭后，发现他的老板所指给他的一个bug在foo.java里。
他试图检出foo.java
...但是版本控制系统不允许他这样做，因为他的兄弟已经把它检出了。
Bob不得不等着他的兄弟吃完午饭回
来（在这个"好"日子用了两个小时），他才可以修正bug。
在一个大型的开放源码工程中，因为开发者可能在任意的时区工作得很晚，给予一个开发者阻止任意地
方的其它开发者继续处理任意文件的能力很明显示无法运转。
他们最终将因为不能够在他们想要的时候开展
项目而感到厌烦。
CVS通过它的无限制的检出模式解决了这个问题。
检出一个文件并不给定开发者对那个文件的排它权。
其
它的开发者也可以对其检出，进行他们自已的修改，并且将其登记回去。
"等一下！
"你可能会说。
"但是后面的登记不是会覆盖前面的吗？
"回答是不会。
详细地回答就是当多个
开发者对同一个文件作了修改CVS会检测，并且自动合并那些改变。
哇噢。
自动的？
不用担心--CVS会很小心，并且将会自动合并那些只要不是对代码的同一行所作的改
动。
如果CVS不能安全的处理这些改动，开发者将不得不手工合并它们。
从此去往何处？
到现在为止，你已经毫不犹豫地着迷于CVS的潜力，并且急不可待地想开始。
第一步就是去得到适合你
的平台的CVS软件。
安装CVS通常就是将其从你下载的压缩包中解开这么一件事。
配置CVS可能要小心一些，
它非常依赖于你使用的平台和你的CVS代码仓库的存放地。
CVShome.org存放了大量的CVS文档：
《IntroductiontoCVS》JimBlandy所写的一篇很棒地在线介绍。
我也推荐《OpenSourceDevelopmentwithCVS》KarlFogel写的。
你可以读一下我写的关于它的评
论在OpenAvenueVOX上。
Karl已经将书中关于CVS的部分置于GPL许可证之下；这篇文档在Karl的站点上
以多种文档格式提供。
《TheCederqvist》--由PerCederqvist所编写的CVS手册--是一个关于CVS信息的全面资料。
有大量的可用在许多平台上CVS附加工具，它们给CVS增加了功能或使得CVS更容易使用。
2.SVN与CVS的比较
1.全局性的版本编号
一个新的版本，并得到一个自增量的版本号N+1，该版本号并不针对某个特定的文件，而是全局性的、针对整个版本库的。
因此，我们可以将Subversion的版本库看作是一个文件系统或文件目录树的数组。
Subversion的全局性版本编号为Subversion带来了诸多的优势：
如对目录或文件执行拷贝，无论涉及多少文件，Subversion不需要对单个文件依次执行拷贝命令，仅仅需要建立一个指向相应的全局版本号的一个指针即可。
2.目录的版本控制
CVS只能对文件进行版本控制，不能对目录进行版本控制，因此CVS没有任何关于文件“移动”（move）操作的概念。
当人为进行文件移动操作时，CVS只能注意到，一个文件在一个位置被删除了，而在一个新位置创建了另外一个文件。
由于它不会连接两个操作，因此也很容易使文件历史轨迹丢失。
设置CVS存储库时，必须非常谨慎地为每个文件选择准确的位置，因为在设置之后，几乎就要一直使用这个位置了。
Subversion将目录作为一类特殊的文件来处理,因此，Subversion像记录普通文件的修改历史一样记录对目录的修改历史，当发生文件/目录的移动、重命名或拷贝操作时，Subversion能够准确记录操作前后的历史联系。
同样，象对文件的不同历史版本进行比较一样，Subversion支持对目录的不同历史版本的比较，清晰展现目录的变化历史。
3.原子性提交
从使用者的角度来看，CVS和Subversion都支持对多个文件修改的批量提交，但二者在实现方式上存在本质的区别。
CVS采用线性、串行的批量提交，即依次地，一个接一个地执行提交，每成功提交一个文件，该文件的一个新的版本即被记录到版本库中，提交时用户提供的日志信息被重复地存储到每一个被修改的文件的版本历史中。
CVS串行批量提交模式的弊端在于－当任何原因造成批量操作的中断时（典型原因包括：
网络中断、客户端死机等），版本库往往处于一个不一致的状态：
原本应该全部入库的文件只有一部分入库，很有可能版本库中的最新版本不能顺利编译，更为严重的是，随着其他的用户执行cvsupdate操作，该不一致性将迅速在开发团队中扩散，从而严重影响团队的开发效率，并存在质量隐患。
SVN彻底消除了CVS的以上弊端。
无论批量提交包含多少文件修改，只有当全部文件修改都成功入库，该提交才变得有效，才对其他用户可见；否则，无论任何原因造成中断，SVN都会自动执行“回滚”（rollback）操作。
换一个说法，SVN保证所有的修改要么全部入库生效，要么一个也不入库，即对版本库不作任何的修改。
这就是SVN的原子性提交（atomiccommit）。
由于SVN的原子性提交特性和全局版本编号方式，当提交成功完成时，一个唯一的、新的全局版本编号产生，而提交时用户提供的日志信息与该新的版本编号关联，只进行一次存储（区别于CVS的按文件重复存储）。
4.差异化的二进制文件处理
CVS能够有效处理文本文件（或ASCII文件，源代码文件），可以对文本文件进行差异化的存储、新旧版本的比较，文件合并等；但对于二进制文件，CVS则明显力不从心。
与CVS不同，Subversion采用统一的二进制差异算法，即对文本文件和二进制文件采用相同的差异比较算法，并以相同的方式在版本库中进行存储：
每次提交后版本库中只存储相对于先前版本的差异，从而可以节省大量的存储空间。
该二进制差异算法不仅应用在版本的存储上，更为重要的是，Subversion对二进制文件与文本文件一视同仁，当客户端需要获取新的版本时（如执行svnupdate），在网络上只有版本的差异被传输，从而大大减少对网络带宽的消耗。
5.双向的差异化－压缩网络传输
对于文本文件，CVS仅仅支持单向的差异化传输：
从CVS服务器到客户端的传输是差异化的，即执行cvsupdate时，只有差异的部分从服务器传输到客户端；而当执行cvscommit时，无论代码变化多少，CVS都需要从客户端向服务器完整传输被修改文件的全部内容，不能只传输差异。
相反，无论是文本文件还是二进制文件，Subversion都进行双向的差异化传输，并且差异化内容还要进行压缩/解压缩的过程。
对CVS而言，操作的成本（网络带宽消耗是最大的操作成本）与被修改的文件的大小成比例，而与修改本身的大小无关；对Subversion而言，操作成本只与修改本身的大小成比例，而与被修改的文件的大小无关。
因此，与CVS相比，Subversion消耗更少的网络带宽。
Subversion更加适合基于互联网（或广域网）进行协作开发的地理上分布的团队—版本服务器集中、单一；客户端广泛分布。
6.高效、快捷创建分支和基线
CVS和Subversion都支持分支（branch）和基线（tag），CVS在创建分支的时候，需要对所有分支文件依次进行操作，因此分支的建立成本（主要是建立分支所需的时间，或消耗的计算资源）与参与分支的文件数量成比例，项目越大，版本库越大，文件越多，分支的建立成本越高；基线（tag）的建立与此类似。
Subversion的分支和基线是通过执行“拷贝”来建立的。
由于Subversion的全局版本号特性，Subversion中分支或基线的创建过程，或Subversion中的“拷贝”过程，真正的操作是在版本库中创建一个到某一全局版本号的指针，不再需要针对众多的单个文件依次执行操作。
因此，该操作的成本为一个很小的常数，并且，分支或基线的建立不需要进行版本的冗余存储，新建立的分支或基线基本不占用版本库空间，分支的后续存储空间的开销也只与修改的大小有关。
7.更好的冲突标识与处理
在CVS中，经常会出现由于用户的疏忽（如，没有注意到冲突，或没有完全处理好冲突）而将仍然带有冲突标识符号的文件直接进行提交，从而在版本库中产生垃圾版本。
Subversion有效解决了CVS的以上问题：
Subversion记录并保持文件的冲突状态，只有当用户明确执行svnresolved命令后，该冲突状态标识才被复位，该文件才能被提交，从而大大减少了将仍然带有冲突标识符号的文件直接进行提交的可能性。
8.更多本地/离线操作
与CVS不同的是，Subversion的.svn目录中还包含了工作拷贝中每一个文件的一个“只读的、干净的”副本。
正是由于该副本的存在，使得Subversion与CVS相比，可以执行更多本地/离线操作，即某些操作不需要访问版本库服务器，因此不需要存在从客户端到服务器的网络链接，当然也不消耗任何网络带宽，这进一步增强了Subversion对广域网的友好支持。
9.元数据管理
与CVS相比，Subversion增加了元数据管理机制。
即可以对版本库中的文件或目录附加任意的“属性”（property），并记录属性的变化历史，也就是对元数据进行版本管理。
Subversion元数据的目的是提供附件的信息以满足流程或过程自动化的需要，以增强Subversion的管理能力和自动化程度。
Subversion自身就通过“属性”来存储一些特殊的信息。
一个使用Subversion元数据的例子：
可以在一些批处理的脚本程序或Subversion的钩子程序（hooks）中创建、访问、修改“属性”元数据来满足流程自动化的要求。
10.集成ApacheWebServer，提供更多的特性
Subversion通过与ApacheWebServer的集成，可以提供基于http/https协议的版本库的访问机制，从而支持Subversion跨越防火墙的安全访问。
除此以外，Subversion还可以利用更多的Apache特性，包括但不限于：
Apache丰富的用户认证机制（包括通过LDAP服务器如WindowsActiveDirectory服务器的用户认证），基于目录路径的精细粒度的访问控制，对传输的网络流量进行压缩/解压缩，浏览版本库目录结构等等。
11.支持WebDAV
Subversion通过与ApacheWebServer的集成，支持WebDAV协议，使得业务用户（businessusers）或非技术用户在不安装任何版本管理客户端的情况下轻松的访问Subversion版本库，不改变业务用户已有使用习惯，支持分布的业务用户对文档的评审、修改并实现版本控制，真正将软件开发的生命周期从开发/技术团队扩展到项目的全部干系人（stakeholder），避免通过电子邮件传递文档的混乱与无序、通过Windows操作系统共享造成的安全漏洞、病毒攻击、历史版本被覆盖或丢失、审计困难等诸多典型问题。
3.CVS与SVN比较表
比较项目
CVS
SVN
权限控制
是否依赖系统帐号
依赖
不依赖
可否对分支授权
否
是
是否支持LDAP认证
否
是
图形化帐号管理
否
是（集中管理平台）
用户可否获取忘记口令，修改口令
否
是（集中管理平台）
目录，文件名变更
否
是
分支
管理
创建分支时间
耗时*
快
分支可见、查询
难
易
二进制文件
二进制优化
否
是
二进制文件标识
手工
自动
二进制文件（图形文件）被破坏
易破坏
不易破坏
事物
处理
原子提交
否
是
修改提交说明
单个文件
是
换行
符
可否指定换行符类型
否
是
检查换行符设定，避免跨平台开发带来的混乱
否
是
功能扩展
CVSROOT
hooks脚本
网络
带宽
网络带宽占用
高
低
脱机命令
否
部分
升级会员 