| 在开源软件领域，并行版本系统（CVS）一直使版本控制的选择。恰如其分的是，CVS本身是一个自由软件，它的非限制性的技法和对网络操作的支持（允许大量的不同地域分散的程序员可以共享他们工作的特性）非常符合开源软件领域合作的精神，CVS和它半混乱状态的开发模型成为了开源文化的基石。
但是像许多其他工具一样，CVS开始显露出衰老的迹象。Subversion是一个被设计成为CVS继任者的新版本控制系统。设计者通过两个办法来争取现有的CVS用户：使用它构件一个开源软件系统的版本控制过程，从感觉和体验上与CVS类似，同时Subversion努力弥补CVS许多明显的缺陷。
Subversion可以在多种不同的操作系统上运行，它的主要用户操作界面是基于命令行的，但现在已经开发出很多可以运行在不同操作系统上的客户端以及多种开发工具的集成套件。
下面从几个方面具体介绍Subversion。
Subversion是什么？Subversion是一个自由/开源版本控制系统，它管理文件和目录可以超越时间。一组文件存放在中心版本库，这个版本库很像一个普通的文件服务器，只是它可以记录每一次文件和目录的修改，这便使你可以取得数据以前的版本，从而可以检查所作的更改。从这个方面看，许多人把版本控制系统当作一种“时间机器”。
Subversion可以通过网络访问它的版本库，从而使用户可以在不同的电脑上使用。一定程度上可以说，允许用户在各自的地方修改同一份数据是促进协作。进展可能非常的迅速，并没有一个所有的改变都会取得效果的通道，由于所有的工作都有历史版本，你不必担心由于失去某个通道而影响质量，如果存在不正确的改变，只要取消改变。
一些版本控制系统也是软件配置管理（SCM）系统，这种系统经过特定的精巧设计来管理源代码，有许多关于软件开发的特性—本身理解编程语言、或者提供构建程序的工具。然而，Subversion不是这样一个系统，它是一个通用系统，可以管理任何类型的文件集，对你这可能是源代码—对别人，可能是一个货物清单或者是数字电影。
Subversion的历史早在2000年，CollabNet, Inc. (http://www.collab.net) 开始寻找CVS替代产品的开发人员，CollabNet提供了一个协作软件套件SourceCast，它的一个组件是版本控制系统。尽管
SourceCast在初始时使用CVS作为其版本控制系统，但是CVS的局限性在一开始就很明显，CollabNet知道迟早要找到一个更好的替代品。遗憾的是，CVS成为了开源世界事实上的标准，因为没有更好的产品，至少是没有可以自由使用的。所以CollabNet决定写一个新的版本控制系统，建立在CVS思想之上的，但是修正其错误和不合理的特性。
2000年2月，他们联系Open Source Development with CVS(Coriolis, 1999)的作者Karl
Fogel，并且询问他是否希望为这个新项目工作，巧合的是，当时Karl正在与朋友Jim Blandy讨论设计一个新的版本控制系统。在1995年，他们两个曾经开办一个提供CVS支持的公司Cyclic
Software，尽管他们最终卖掉了公司，但还是天天使用CVS进行日常工作，在使用CVS时的挫折最终促使他们认真地去考虑如何管理标记版本的数据，而且他们当时不仅仅提出了“Subversion”这个名字，并且做出了Subversion版本库的基础设计。所以当CollabNet提出邀请的时候，Karl马上同意为这个项目工作，同时Jim也得到了他的雇主，RedHat软件赞助他到这个项目并提供了一个宽松的时间。CollabNet雇佣了Karl和Ben
Collins Sussman，详细的设计从三月开始，在Behlendorf 、CollabNet、Jason Robbins
和 Greg Stein（当时是一个独立开发者，活跃在WebDAV/DeltaV系统规范阶段）的恰当激励的帮助下，Subversion很快吸引了许多活跃的开发者，结果是许多有CVS经验的人们很乐于有机会为这个项目做些事情。
最初的设计小组固定在简单的目标上，他们不想在版本控制方法学中开垦处女地，他们只是希望修正CVS，他们决定Subversion匹配CVS的特性，保留相同的开发模型，但不复制CVS明显的缺陷。尽管它不需要成为CVS的继任者，它也应该与CVS保持足够的相似性，使得CVS用户可以轻松的做出转换。
经过14个月的编码，2001年8月31日，Subversion自己能够“成为服务”了，开发者停止使用CVS保存Subversion的代码，而使用Subversion本身。
当CollabNet开始这个项目的时候，曾经资助了大量的工作（它为全职的Subversion开发者提供薪水），Subversion像许多开源项目一样，被一些激励知识界精英的宽松透明的规则支配着。CollabNet的版权许可证完全符合Debian的自由软件方针，也就是说，任何人可以自由的下载，修改和重新发布，不需要经过CollabNet或其他人的允许。
Subversion的特性当讨论Subversion为版本控制领域带来的特性的时候，通过学习它在CVS基础上所作的改进会是比较有效的方法。如果你不熟悉CVS，你会不太明白所有的特性，如果你根本就不熟悉版本控制，你会瞪着眼无所适从，你最好首先阅读一下有关版本控制的其他介绍。
Subversion提供：
版本化的目录
CVS只记录单个文件的历史，但是Subversion实现了一个可以跟踪目录树更改的“虚拟”版本化文件系统，文件和目录都是有版本的。
真实的版本历史
因为CVS只记录单个文件的版本，对于拷贝和改名—这些文件经常发生的操作，会改变一个目录的内容—在CVS中并不支持。在CVS里你也不可以用一个完全不同的文件覆盖原来的同名文件而又不继承原来文件的历史。通过Subversion，你可以对文件或是目录进行增加、拷贝和改名操作，也可以新增一个具有干净历史的文件。
原子提交
一系列的改动，要么全部提交到版本库，要么一个也不提交，这样可以让用户构建一个所要提交修改的逻辑块，防止部分修改提交到版本库。
版本化的元数据
每一个文件或目录都有一套属性—键和它们的值，你可以建立并存储任何键/值对，属性也是随时间的流逝而纳入版本控制的，很像文件的内容。
可选的网络层
Subversion在版本库访问方面有一个抽象概念，利于人们去实现新的网络机制，Subversion可以作为一个扩展模块与Apache结合，这给了Subversion在稳定性和交互性方面很大的好处，可以直接使用服务器的特性—认证、授权和传输压缩等等。也有一个轻型的，单独运行的
Subversion服务，这个服务使用自己的协议可以轻松的用SSH封装。
一致的数据操作
Subversion表示文件是建立在二进制文件区别算法基础上的，对于文本（可读）和二进制（不可读）文件具备一致的操作方式，两种类型的文件都压缩存放在版本库中，区别信息是在网络上双向传递的。
有效率的分支和标签
分支与标签的代价不与工程的大小成比例，Subversion建立分支与标签时只是拷贝整个工程，使用了一种类似于硬链接的机制，因而这类操作通常只会花费很少并且相对固定的时间。
可修改性
Subversion没有历史负担，它由一系列良好的共享C库实现，具有定义良好的API，这使得Subversion非常容易维护，可以轻易的用其他语言操作。
Subversion的架构俯视Subersion的设计，可以看出，一端是保存你所有纳入版本控制的数据的Subversion版本库，在另一端是你的Subvesion客户端程序，管理着所有纳入版本控制数据的本地影射（叫做“工作拷贝”），在这两极之间是各种各样的版本库访问（RA）层，一些使用电脑网络通过网络服务器访问版本库，一些则绕过网络服务器直接访问版本库。 |