SVN和Perforce的对比

 

1.概要

使用Subversion通常会导致生产力下降和高的管理费用。尽管其前期许可成本为零,Subversion由于工作流程欠佳和过时的功能迫使您在代码管理上花费宝贵的资源。生产力的净损失要比任何许可费昂贵得多。

Subversion的常见问题包括:

•合并失败:不完整的合并算法几乎没有实用性,最简单的问题有时也需要数小时才能解决

•耗时的发布管理:无法跟踪更改到各个发行分支的传播,强制长时间冻结代码。

•性能问题:存储库中的大量文件或大量修订大大降低了性能,导致降低开发人员的生产力。

•弱访问控制:粗粒度的访问控制很难控制用户的读写位置。

Perforce为那些希望恢复因使用Subversion而损失生产力和资源的客户提供有吸引力的解决方案。在一个集成平台中提供成熟的功能,可以选择集中式或分布式工作流程,全面的Git管理生态系统和先进的安全措施。该公司还提供专门的技术支持和专业服务团队,以确保您尽可能地平滑迁移到Perforce。

2.对比

 

2.1比较矩阵

2.2合并

Subversion仅提供基本的合并历史记录跟踪,但在许多情况下会失败。这样的合并可能非常缓慢,并经常导致不必要的合并冲突,对于重命名并移动尤其如此。一些客户报告说他们在每个发布周期中花费最多可达5个工作日来处理Subversion合并。

Perforce凭借其先进和成熟的合并跟踪机制自动跟踪所有分支操作的历史记录,包括重命名和移动。更改可以安全地在所有分支间合并,并且集成算法可以确定最佳共用基准版本来减少合并冲突。

失败的合并是Subversion管理员的头等大事,这经常导致用户高成本和低效地花很多时间进行必要的合并,或者让团队完全放弃使用分支和合并。

 

2.3发布管理

在Subversion中,用户仅通过约定命名来标识分支,这些分支之间没有关系。没有内置的方法来识别需要将修复应用到哪些分支,并且识别出所需的更改很复杂和痛苦。

Perforce Streams提供一个指引式的分支框架,遵循主线,开发和发布的最佳实践。借助P4V Streams Graph,开发人员和版本经理可以很容易地:

•发现哪些更改需要在不同的流之间传播

•安全快速地执行合并

这些功能使代码管理员可以轻松跨不同的代码基线跟踪修复。

错误修复通常需要应用于多个发行分支,以避免回归。如果没有关于需要在何处应用这些更改的指导,代码管理者需要花费大量时间来手工跟踪单个更改。在Subversion中,这往往导致频繁的代码冻结和分支锁定。

 

2.4性能和可伸缩性

Subversion的体系结构使用正向增量方式存储版本。对于每次checkout,它必须从头一步步叠加所有的增量改动来构造出最新版本。这个操作受CPU的限制,而且很耗时。因此,Subversion不适用于大量用户和数据。随着文件数量和文件版本的增加,创建或者更新工作副本等获取最新版本的操作,性能会严重下降。Subversion通常仅限于约250个用户,并且由于性能和维护问题,存储库很少超过1 TB。

Perforce经过验证的安装具有10,000多个用户,访问单个存储库。许多Perforce存储库保存有数百万个文件和TB级的数据,在某些情况下甚至高达PB级。案例研究表明,Perforce同步大量文件时,速度比SVN快5至10倍。

当项目成熟时,它们的代码库和历史记录就会增长。如果仓库无法跟上增加的负载,该项目会变得不可维护。过去耗时数秒的操作现在可能要花费几分钟,这将严重影响开发人员的工作效率。如果您打算将Subversion连接到持续集成系统,则情况会更加恶化,系统每天的总读取操作可达数百万次,是250个用户创建的负载的1,000倍。

 

2.5集中和分散的工作流程

Subversion本身仅提供传统的集中式工作流程,需要与中央服务器的持久连接。

除了传统的集中式工作流程,Perforce还提供分布式版本控制系统(DVCS)功能允许用户脱机工作,同时仍然可以使用所有Perforce工具和界面。Helix还允许专门的Git开发人员使用完整版本Git的功能,同时在幕后推向中央Perforce存储库,提供了两全其美的优势。

分布式版本控制允许开发人员快速创建本地分支而不影响中央存储库的大小。最后,工作仍然需要存储在中央存储库中,以进行共享,查看和连续集成。Helix在满足大型企业的需求时也能给开发人员提供喜欢的工作流程。

 

2.6 Git管理

Subversion没有用于管理Git存储库的工具。

Helix 提供了许多开发人员喜欢的基于纯Git的工作流程选项,这也使项目易于管理。管理项目和团队,保持所有项目、跟踪的问题和在基于Git的Wiki中保存的重要项目信息可以轻松获得。可以自动将您团队的工作镜像到Helix版本控制引擎,以获得企业级的协作、可见性、安全性和控制性。

协作平台需要灵活地适应其用户偏好,否则这些用户将转到其他地方。如今,许多开发人员更喜欢工作断开连接,将其工作存储和版本控制到本地存储库与他人分享。Git已成为非常流行的分布式版本控制工具,通常较大的组织将有一些团队使用Git,而其他团队使用不同的工具和工作流程。借助Perforce Helix,您可以管理使用Git的任何团队和项目,同时自动将工作镜像到Helix版本控制引擎。这为所有项目和团队带来了企业级的可见性,安全性和控制。

2.7文件历史

Subversion仅提供了一个简单的log命令,带有少量过滤器选项。一个查找特定用户所作的更改或者删除的文件的简单报告可能需要几分钟,因为它需要列出整个项目的历史记录并过滤输出。

Perforce从命令行和p4v提供了一系列强大的工具,P4V创建有关文件历史记录的报告。P4V中的工具,例如TimeLapse View,Revision Graph或者Folder Diff是查找变更的源头和历史的很有用工具。当公司将其完整的Subversion存储库迁移到Perforce,他们经常会发现许多他们不知道的变更历史细节。

尽管传统的中央服务器具有许多优点(例如更紧密协作),能够离线工作的趋势仍在增长。有时开发人员在移动中,无法访问公司网络。更重要的是,分布式版本控制允许开发人员可以快速创建本地分支机构而不会影响中央存储库的分支规模。最后,工作仍需要存储在中央的存储库用于共享,审阅和持续集成。

 

2.8全球团队

Subversion没有内置的缓存或复制技术,必须依靠低带宽和高延迟的WAN。或者,管理员必须安装昂贵的第三方解决方案,这会增加成本和额外的复杂性。

Perforce提供易于安装且几乎免维护的用于小型远程办公室的代理解决方案和灵活的用于大型办公室的复制解决方案,无需额外费用。副本可以设置为完全,过滤或按需缓存以满足您的要求和带宽。

许多开发团队正在走向全球,来自世界各地的用户可以每天24小时访问并提交存储库。如果没有适当的缓存或复制技术,远程团队会饱受延迟和带宽耗尽的困扰,严重影响了生产力。Perforce Helix vs. Subversion:为什么今天改用Perforce?| 7

比较

 

2.9安全

Subversion存储库中没有内置的安全性,也没有访问控制,用户或组的概念。验证用户并确定用户是否有权访问存储库,您还必须安装和配置Apache,这增加了额外的复杂性,并且需要其他资源。Apache访问控制通常也是限于整个存储库。

除了完整的访问控制功能,Helix平台包括Helix Threat Detection,可主动发现Helix版本控制引擎中存储的知识产权所面对的威胁。它将高级行为分析应用于评估每个威胁事件的风险水平,识别出最关键的威胁。这使您能够立即检测到受到威胁的帐户,恶意软件和盗窃企图。

每周似乎都有一些公司因为其数据被盗成为头条新闻。实际上,最近的IP委员会报告估计了数据被盗引起的损失,仅在美国就达到了每年度 3000亿美元。常规安全措施还不足以防止您最有价值的知识产权被盗,组织需要有效的最后一道防线防止数据被盗。

 

3结论

诸如Subversion之类的开源产品并非“免费”。他们伴随着例如生产力损失,延迟产品发布以及增加维护等隐性成本,可能会比前期节省的许可费用高一个数量级。

我们邀请您免费试用Perforce(最多5位用户或1000文件以下不限用户数)

 

请发邮箱至sales@shdsd.com或电话联系我们的销售团队。