八大特性对比显示SVN与CVS的优缺点

本文主要介绍分析一下SVN与CVS优缺点,CVS和SVN的比较类似与比较C++和Java,很明显CVS和SVN都远比SourceSafe强大的多,如同C++和Java比Basic强大的多。CVS代表了几乎代码控制系统的所有功能项,尽管有时他的实现并不很方便。SVN,修正并添加了一些CVS并不拥有功能。例如,创建标志和分支dubious,你在编辑文件是其他人不会有任何通知。这有点象Java的发明者:他们认为你不需要指针他们就在Java里面取消了指针,Java里也没有操作符重载。
编号对比项  
       CVS与SVN   
      1.SVN与CVS存储类型格式
CVS是个基于RCS文件的版本控制系统。每个CVS文件都不过是普通的文件,加上一些额外信息。这些文件会简单的重复本地文件的树结构。因此,不必担心有什么数据损失,如果必要的话你可以手工修改RCS文件。SVN是基于关系数据库的(BerkleyDB)或一系列二进制文件的(FS_FS)。一方面这解决了许多问题(例如,并行读写共享文件)以及添加了许多新功能(例如运行时的事务特性。)。然而另一方面,数据存储由此变得不透明,或是说并不那么用户友好了。那就是为什么工具软件,对仓库(数据库)变得那么重要了。  
      2.SVN与CVS速度
CVS比较慢。整体而言,由于架构实现的不同,SVN的确比CVS快很多。在网络上它只传输很少的信息并支持更多的离线模式的功能。但这也是有代价的。速度的代价就是巨大的存储(完全备份所有的工作文件)。  
      3.SVN与CVS标志&分支(!!!重要)
在我们看来,这些实现是适宜的。SVN开发员自认为把采用标志和分支而抛弃了其他三件东西是件了不起的事。实际上这意味着他们把这个概念替换为在档案库内部复制文件或目录以便保存日志。这样一来,无论标志创建还是分支创建都只是仓库内部的文件复制了。在SVN的开发员看来,这是个很优雅的决策,这让生活变得如此简便。而我们看来,这丝毫没有什么值得骄傲之处。对分支而言,事情还不怎么糟糕,现在分支不过是在仓库内部的一个单独的目录而已了,不象早期还有些什么交错。对标志而言,事情就不那么妙了。你已经不能对代码加标志了,这个功能就这么没了。在某种程度上说,SVN全文件编号补足了这个缺陷,SVN里整个仓库都有版本号,但不是针对单个文件。当然,如果你认为一个符号标志比一个四位编码有效的话,我们业无话可说。  
      4.SVN与CVS元数据

CVS只允许存储文件。SVN允许一个文件有任意都的可命名属性。功能十分完全,但不知到有什么用。

 5.SVN与CVS文件类型
CVS最初是为文本文件存储而设计的。因此其他文件类型(二进制,统一码)文件的支持几乎没有,如需要的话则要有其他信息,并且客户端服务器端都要调整。SVN会关心所有的文件类型,不需要你来手工操作。  
      6.SVN与CVS滚回
CVS允许任意的滚回,在任意一个已递交的版本上,尽管着要花些时间(所有的文件都要分别处理)。SVN不允许递交后滚回。我们建议把仓库里好的状态版本加到末尾,覆盖掉损坏的版本。而损坏的版本无论如何也是会存在数据库里的。(svn的滚回操作实际上是merge操作).  
      7.SVN与CVS事务
CVS中的“零或一”事务原则根本没有实现。如果检入几个文件的话(加到服务器上),很有可能部分文件完成了,而另几个没有。做为一个潜规则,手工纠正这些并且对余下的文件(而不是所有文件)一一重复检入。这样这些文件将在两阶段中被检入。但至今为止,因为这个功能缺少而导致的数据仓库损坏的案例还没有出现过。SVN的确支持“零或一”事务原则,这是SVN的一大优势。  
      8.SVN与CVS可用性
CVS可以用在你需要的地方,支持完善。SVN并未广泛运用,一些支持项目仍然没有实现。  
      SVN并不是CVS的替代品。他只是个不同的系统,类似于CVS。它有些特有的功能,足以作为采用它的理由。这些功能使他更适合于开发环境,例如对PowerBuilder。下面你可以找到两者的相对优势、劣势。我们假设余下的东西两者没有什么大差别。如果你对两者都举棋不定,我们建议试试两个系统,注意观察下面几个指标。你也可以到网上看看两者之间的讨论。  
      注意:这份评价表并不代表最终意见,两个系统仍然在开发之中。
 
 


MyISAM InnoDB 区别 InnoDB和MyISAM是许多人在使用MySQL时最常用的两个表类型,这两个表类型各有优劣,视具体应用而定。基本的差别为:MyISAM类型不支持事务处理等高级处理,而InnoDB类型支持。MyISAM类型的表强调的是性能,其执行数度比InnoDB类型更快,   MyISAM 和 InnoDB 讲解   InnoDB和MyISAM是许多人在使用MySQL时最常用的两个表类型,这两个表类型各有优劣,视具体应用而定。基本的差别为:MyISAM类型不支持事务处理等高级处理,而InnoDB类型支持。MyISAM类型的表强调的是性能,其执行数度比InnoDB类型更快,但是不提供事务支持,而InnoDB提供事务支持已经外部键等高级数据库功能。   以下是一些细节和具体实现的差别:   ◆1.InnoDB不支持FULLTEXT类型的索引。   ◆2.InnoDB 中不保存表的具体行数,也就是说,执行select count(*) from table时,InnoDB要扫描一遍整个表来计算有多少行,但是MyISAM只要简单的读出保存好的行数即可。注意的是,当count(*)语句包含 where条件时,两种表的操作是一样的。   ◆3.对于AUTO_INCREMENT类型的字段,InnoDB中必须包含只有该字段的索引,但是在MyISAM表中,可以和其他字段一起建立联合索引。   ◆4.DELETE FROM table时,InnoDB不会重新建立表,而是一行一行的删除。   ◆5.LOAD TABLE FROM MASTER操作对InnoDB是不起作用的,解决方法是首先把InnoDB表改成MyISAM表,导入数据后再改成InnoDB表,但是对于使用的额外的InnoDB特性(例如外键)的表不适用。   另外,InnoDB表的行锁也不是绝对的,假如在执行一个SQL语句时MySQL不能确定要扫描的范围,InnoDB表同样会锁全表,例如update table set num=1 where name like “%aaa%”   两种类型最主要的差别就是Innodb 支持事务处理与外键和行级锁.而MyISAM不支持.所以MyISAM往往就容易被人认为只适合在小项目中使用。   我作为使用MySQL的用户角度出发,Innodb和MyISAM都是比较喜欢的,但是从我目前运维的数据库平台要达到需求:99.9%的稳定性,方便的扩展性和高可用性来说的话,MyISAM绝对是我的首选。   原因如下:   1、首先我目前平台上承载的大部分项目是读多写少的项目,而MyISAM的读性能是比Innodb强不少的。   2、MyISAM的索引和数据是分开的,并且索引是有压缩的,内存使用率就对应提高了不少。能加载更多索引,而Innodb是索引和数据是紧密捆绑的,没有使用压缩从而会造成Innodb比MyISAM体积庞大不小。   3、从平台角度来说,经常隔1,2个月就会发生应用开发人员不小心update一个表where写的范围不对,导致这个表没法正常用了,这个时候MyISAM的优越性就体现出来了,随便从当天拷贝的压缩包取出对应表的文件,随便放到一个数据库目录下,然后dump成sql再导回到主库,并把对应的binlog补上。如果是Innodb,恐怕不可能有这么快速度,别和我说让Innodb定期用导出xxx.sql机制备份,因为我平台上最小的一个数据库实例的数据量基本都是几十G大小。   4、从我接触的应用逻辑来说,select count(*) 和order by 是最频繁的,大概能占了整个sql总语句的60%以上的操作,而这种操作Innodb其实也是会锁表的,很多人以为Innodb是行级锁,那个只是where对它主键是有效,非主键的都会锁全表的。   5、还有就是经常有很多应用部门需要我给他们定期某些表的数据,MyISAM的话很方便,只要发给他们对应那表的frm.MYD,MYI的文件,让他们自己在对应版本的数据库启动就行,而Innodb就需要导出xxx.sql了,因为光给别人文件,受字典数据文件的影响,对方是无法使用的。   6、如果和MyISAM比insert写操作的话,Innodb还达不到MyISAM的写性能,如果是针对基于索引的update操作,虽然MyISAM可能会逊色Innodb,但是那么高并发的写,从库能否追的上也是一个问题,还不如通过多实例分库分表架构来解决。   7、如果是用MyISAM的话,merge引擎可以大大加快应用部门的开发速度,他们只要对这个merge表做一些select count(*)操作,非常适合大项目总量约几亿的rows某一类型(如日志,调查统计)的业务表。   当然Innodb也不是绝对不用,用事务的项目如模拟炒股项目,我就是用Innodb的,活跃用户20多万时候,也是很轻松应付了,因此我个人也是很喜欢Innodb的,只是如果从数据库平台应用出发,我还是会首选MyISAM。   另外,可能有人会说你MyISAM无法抗太多写操作,但是我可以通过架构来弥补,说个我现有用的数据库平台容量:主从数据总量在几百T以上,每天十多亿 pv的动态页面,还有几个大项目是通过数据接口方式调用未算进pv总数,(其中包括一个大项目因为初期memcached没部署,导致单台数据库每天处理 9千万的查询)。而我的整体数据库服务器平均负载都在0.5-1左右。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值