1概要
比
功能点 | CVS | Perforce |
分支与合并 | CVS提供分支,但需要手动
跟踪合并历史记录。 |
Perforce分支会自动跟踪所有分支操作的历史记录。 |
分布式开发 | 没有针对远程开发的高性能解决方案可用。 | Perforce提供多种分布式开发方案:
1.代理服务器方案:为远程用户提供缓存解决方案,仅需极少的管理开销,无额外费用成本。 2.Master服务器+Replica服务器:不涉及元数据写入的操作可在本地Replica服务器完成。除此以外,Replica服务器可以起到备份的作用。 3. Commit服务器+Edge服务器:Edge服务器拥有部分自有元数据,最大化减少对远程服务器的访问。 |
原子事务 | 没有原子变更机制,并且无法将对相关文件的更改分组。 | 原生支持变更集,从而使用户能够跟踪新加功能或故障修复相关联的文件。 |
可扩展性和性能 | 集中元数据记录所有用户和文件活动。已在多于10,000名用户的环境中部署。支持PB级的数据存储。支持多线程上传和下载。 | |
缺陷追踪 | 不属于CVS,需要单独使用缺陷跟踪解决方案。 | Perforce提供称为Jobs的基本缺陷跟踪系统,并与领先的第三方缺陷跟踪系统集成。 |
与相关工具集成 | 可通过开源 区获得集成。 | 设计了许多第三方工具专门与Perforce协作。 |
支持 | 额外付费,由第三方提供。 | 超过40万用户所信赖的支持服务。 |
2分支与合并
Perforce分支模型功能强大且灵活。它能够对成千上万的文件创建分支,并追踪分支间的所有合并,合并跟踪是支持同步分支的重要特性。Perforce引入了文件的原始版本和分支版本,以便于跟踪所有增量更改。用户可以使用Perforce自动跨多个分支合并而不是手工追踪分支间变化。这使得各种开发方案成为可能,例如使用特定于客户的版本,实验分支,个人或任务分支,以及经典的release分支模式。内置的图形工具(请参见图1)显示每个文件的分支/合并历史记录。

图1:Perforce 版本图显示文件的分支/合并历史
3分布式开发
CVS不提供可扩展的远程开发解决方案。用户必须远程访问中央服务器,如果用户使用快速,可靠的 络连接,这种方式是可行的,但对于位于远程的用户来说效率低下。Replication解决方案可从第三方提供商处购买。
Perforce的分布式架构包括完整的复制服务器,改进的远程仓库,以及DVCS(Distributed Version Control System)。Perforce Proxy在远程缓存文件并向远程用户提供服务,从而减少慢速WAN上的流量。所有本地或远程用户都连接到同一中央仓库,并查看完全相同的项目文件。分布式Perforce进行开发不会增加额外的开销,Perforce分布式架构只需要极小的管理成本(请参见图2)。




说明:
1.proxy服务器管理开销最小,仅起到缓存文件的作用。所有元数据均需要访问远端服务器。
2.Master-Replica架构除了缓存文件之外,对元数据的读操作,都可本地完成,例如查看标签,查看修改记录等。另外具有备机的作用。管理开销中等。
3.Commit-Edge架构,除了Master-Replica具有的功能之外,对工作区相关元数据的读/写可以本地进行。但因为与上游服务器的元数据不尽相同,所以不具有备份功能,通常需要为Edge和Commit服务器另外搭建备机。管理开销高于Master-Replica架构。
图2:Perforce内建分布式开发架构
4原子事务
CVS没有原子变更机制,无法将相关文件的更改分组。在提交修改时,文件之间的关联关系会丢失,除非人为的根据提交时间或者共同的注释来识别。如果部分文件提交时失败了,则代码库会处于不一致的状态。
5可伸缩性和性能
CVS架构不支持用于跟踪分支,标签和更改历史记录的集中式数据库,因此,所有更改历史记录必须以RCS形式存储在每个版本化文件中,这包括所有分支和标签信息。用户更新客户端文件信息需要对客户端环境与存储库进行耗时的比较。随着存储库中文件数量和大小的增加,所有相关的软件版本管理操作需要花更多时间执行。因为请求的文件需要更新分支和标签信息,并发用户经常处于等待状态。改善性能只能通过删除物理文件中陈旧的文件历史来实现。
Perforce在设计之初就将速度放在首位。Perforce性能保持线性,不会因为文件的修订版本数的增加或文件的大小而损耗性能。Perforce的内置关系数据库维护所有元数据并将其与相关文件分离。标签,分支和 告是直接在数据库中完成,而不是更新并扫描特定分支树中的所有文件。Perforce服务器已成功部署在支持超过10,000个用户的环境中。
6性能测试
为了对比Perforce测试CVS性能,对比基准测试旨在反映真实的开发人员日常工作。在某些情况下,单个命令被使用。在其他情况下,使用脚本调用多个命令。在所有情况下,通过命令行工具来执行功能等效的命令集。通过比较可以了解这两种产品在现实环境中的表现。
6.1 测试环境
测试环境使用2009年的通用开发环境。配置超出了CVS和Perforce的最低建议配置。环境组成:
? 络:服务器和客户端在同一 段1 Gbps 络
?服务器操作系统:Windows Server 2008(标准)SP1(32位)
?客户端操作系统:Windows XP Professional SP2(64位)
?服务器硬件:Dell PowerEdge 1850双3.3 GHz Xeon处理器X5470、132GB硬盘和16GB RAM
?客户端硬件:具有Intel的Dell Precision 490 Xeon 5130 2.0 GHz处理器和2GB RAM
6.2测试过程
测试从两个新安装状态的源代码控制系统开始。在每个系统上交替运行测试。所有开发人员和源文件导入测试都是自动化完成并且使用DOS time命令计时,精确到.01秒的粒度。软件安装为外部计时。
因为测试将调用文件系统缓存或数据库缓存,测试运行了三次,将第二次和第三次迭代的平均时间记录下来。这模拟了许多文件通过构建和源代码搜索被重复访问的场景。
当需要一系列命令来完成一个单一测试时,则使用DOS批处理文件。
除了移除交互输入以外没有使用其它性能优化的技巧。
测试旨在比较两种产品在正常的开发人员使用场景的表现。对于所有处理,使用自动合并,因为测试数据构造为避免文件冲突。测试任务:
?服务器安装
?客户端安装
?从本地文件系统导入源
?填充工作区
?更新工作区(在服务器上无更改)
?对所有文件打标签
?删除服务器上的文件
?取消删除服务器上的文件
?分支文件
?合并回父分支
?分支二进制文件
6.3测试数据
测试数据是两个开源软件的组合
软件包:Apache httpd 2.2.14和Apache Tomcat 6.0.20。一个“小”项目包含每个项目的一个副本包:4,480个文件,总计56.3MB。一个“大型”项目在单独的树中包含每个软件包的四个副本:
33,920个文件,总计417MB。大型项目的测试在每棵树上执行相同的操作。二进制文件的测试数据由217个文件(MPG,EXE和TAR)组成,总计1GB。
6.4检测结果
安装CVS比安装Perforce更复杂,但不算非常复杂。Perforce在18个测试中有16个的表现优于CVS。详细的测试结果如下。
说明:除非另有说明,否则时间以秒为单位
任务 | CVS | Perforce |
安装服务器 | 20分钟 | 10分钟 |
安装客户端 | 20分钟 | 10分钟 |
任务 | 小项目 | 大项目 | ||
CVS | Perforce | CVS | Perforce | |
导入源文件 | 13.78 | 9.40 | 51.3 | 41.10 |
填充工作区 | 34.81 | 9.97 | 116.08 | 80.70 |
更新工作空间(无更新) | 6.39 | 3毫秒 | 61.76 | 39毫秒 |
标签/基线所有文件 | 14.27 | 11毫秒 | 47.87 | 36毫秒 |
删除服务器上的文件 | 58.32 | 2.0 | 232.13 | 11.81 |
取消删除服务器上的文件 | 33.11 | 27.10 | 109.10 | 136.70 |
分支文件 | 14.81 | 9毫秒 | 44.63 | 2.90 |
合并回到父分支 | 15.60 | 49毫秒 | 15.82 | 1.34 |
二进制文件:添加文件 | 不适用 | 不适用 | 55.19 | 125.05 |
二进制文件:分支文件 | 不适用 | 不适用 | 8.05 | 8毫秒 |
7缺陷追踪
CVS不包括缺陷跟踪。
8与相关工具的集成
开源 区支持CVS,不同的GUI和主流IDE插件可用。
Perforce具有成熟的多平台GUI和适用于最新IDE的插件。与领先的第三方集成技术包括:
?缺陷跟踪系统(Jira等)
?软件构建和测试工具(Jenkins等)
?图形工具(maya等)
?IDE
?合并和差异工具
?敏捷工具
?代码审查工具
9系统管理和支持
CVS具有可完全访问源代码的优势,但是仅当您精通C语言并有时间进行深入研究时才有用,可以从各种第三方途径获得CVS的商业支持。
Perforce的独立软件版本管理系统易于维护,将宝贵的工程人才从挂载专用磁盘卷、
配置文件系统,或担心第三方许可证这些繁琐的事务中解脱出来。
专业快速的技术支持是Perforce的一个标志,并在试用期间提供全面的技术支持。
声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!