Subversion与CVS的对比——非功能性对比（一）

　　Subversion与CVS的对比——非功能性对比：性能、可用性、可扩展性

　　一、层次化的体系架构

　　尽管CVS 是开放源代码的，但同样由于历史的原因，即使是CVS 的主要开发和维护人员也认为目前CVS 的代码很难进行后续的维护和扩展，而这正是Subversion 被重写的主要原因之一。

　　Subversion 具备设计良好的三层体系架构 － 版本库层（Repository Layer），版本库访问层（Repository Access Layer），和客户端层（Client Layer）。 Subversion 在层与层之间定义了明确的接口，使之具备更好的扩展性。

　　Subversion 的体系架构如下图所示：

　　二、可选的后台版本库实现

　　CVS 的版本库以普通的文件系统方式实现；Subversion 的版本库支持两种实现方式：以嵌入式的数据库BerkeleyDB 实现，或，采用特定格式的普通文件系统FSFS 方式实现。二者在可扩展性、性能、备份/恢复等方面各有特色，用户可以根据自身的实际需求进行灵活的选择。

　　三、更好的性能和可用性

　　由于CVS 主要针对文本文件的版本处理而设计，CVS 在处理大文件时存在性能和可用性问题 － CVS 在执行提交时需要向服务器传输整个文件的内容。一方面，处理文件的大小受制与客户端可用内存的多少；另一方面，大文件的处理将占用服务器的绝大部分资源，可能导致服务器性能严重下降，使得其他用户无法访问和工作，甚至出现服务器宕机。

　　Subversion 从设计上根本杜绝了CVS 的上述问题。Subversion 能够处理任意大小的文件，包括比可用内存还大的文件，并且无论是在客户端还是在服务器端，Subversion 始终只需要一个相对小、相对固定的内存开销 － Subversion 能够进行双向的差异化/压缩的网络传输，而且无论差异的大小，Subversion 始终以大小固定的管道方式或流模式（stream）执行网络传输。事实上，由于客户端参与了差异的计算，Subversion 让大量的客户端一起分担服务器的处理负荷，从而从整体上提高了Subversion 的性能和可用性。

　　四、可解析、格式规范的输出

　　从用户的角度来看，命令行方式下的Subversion 的风格与CVS 的风格非常类似，但Subversion 还是做了重大的改进：Subversion 命令行方式下的输出经过了“认真、仔细”的设计，使得其输出不仅便于“人”的阅读和理解，同样便于程序脚本的自动化解析，或者说，适合“机器”的阅读和理解。因此，在Subversion 下编写批量的自动化脚本程序更加容易，脚本工作更加可靠。

　　五、更好的本地化、国际化支持

　　Subversion 从一开始就充分考虑到本地化（ Localization ， L10N ） 、国际化（Internationalization， I18N）方面的需求，无论是对多字节文件，多字节文件名的版本管理，还是客户端工具的用户界面/输出提示信息本地化等，Subversion 都比CVS 做得更好。