Subversion是一个自由/开源的版本控制系统。也就是说，在Subversion管理下，文件和目录可以超越时空。也就是Subversion允许你数据恢复到早期版本，或者是检查数据修改的历史。正因为如此，许多人将版本控制系统当作一种神奇的“时间机器”。
Subversion的版本库可以通过网络访问，从而使用户可以在不同的电脑上进行操作。从某种程度上来说，允许用户在各自的空间里修改和管理同一组数据可以促进团队协作。因为修改不再是单线进行，开发速度会更快。此外，由于所有的工作都已版本化，也就不必担心由于错误的更改而影响软件质量—如果出现不正确的更改，只要撤销那一次更改操作即可。
某些版本控制系统本身也是软件配置管理（SCM）系统，这种系统经过精巧的设计，专门用来管理源代码树，并且具备许多与软件开发有关的特性—比如，对编程语言的支持，或者提供程序构建工具。不过Subversion并不是这样的系统。它是一个通用系统，可以管理任何类型的文件集。对你来说，这些文件这可能是源程序—而对别人，则可能是一个货物清单或者是数字电影。
If you're a user or system administrator pondering the use of Subversion, the first question you should ask yourself is: "is this the right tool for the job?" Subversion is a fantastic hammer, but be careful not to view every problem as a nail.
If you need to archive old versions of files and directories, possibly resurrect them, or examine logs of how they've changed over time, then Subversion is exactly the right tool for you. If you need to collaborate with people on documents (usually over a network) and keep track of who made which changes, then Subversion is also appropriate. This is why Subversion is so often used in software development environments — programming is an inherently social activity, and Subversion makes it easy to collaborate with other programmers. Of course, there's a cost to using Subversion as well: administrative overhead. You'll need to manage a data-repository to store the information and all its history, and be diligent about backing it up. When working with the data on a daily basis, you won't be able to copy, move, rename, or delete files the way you usually do. Instead, you'll have to do all of those things through Subversion.
Assuming you're fine with the extra workflow, you should still make sure you're not using Subversion to solve a problem that other tools solve better. For example, because Subversion replicates data to all the collaborators involved, a common misuse is to treat it as a generic distribution system. People will sometimes use Subversion to distribute huge collections of photos, digital music, or software packages. The problem is, this sort of data usually isn't changing at all. The collection itself grows over time, but the individual files within the collection aren't being changed. In this case, using Subversion is "overkill".[2] There are simpler tools that efficiently replicate data without the overhead of tracking changes, such as rsync or unison.
早在2000年，CollabNet, Inc. (http://www.collab.net)就开始寻找CVS替代产品的开发人员。CollabNet提供了一个名为CollabNet企业版（CEE）的协作软件套件。这个软件套件的一个组成部分就是版本控制系统。尽管CEE在最初采用了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时的挫折促使Jim认真的思考如何管理版本化的数据，并且他当时不仅使用了“Subversion”这个名字，并且已经完成了Subversion版本库的最初设计。所以当CollabNet提出邀请的时候，Karl马上同意为这个项目工作，同时Jim也找到了他的雇主—Red Hat软件公司—允许他到这个项目工作，并且没有限定最终的期限。CollabNet雇佣了Karl和Ben Collins Sussman，详细设计工作从三月开始，在Behlendorf 、CollabNet、Jason Robbins和Greg Stein（当时是一个独立开发者，活跃在WebDAV/DeltaV系统规范制订工作中）恰到好处的激励下，Subversion很快吸引了许多活跃的开发者，结果是许多对CVS有过失望经历的人很乐于为这个项目做些事情。
最初的设计小组设定了简单的开发目标。他们不想在版本控制方法学中开垦处女地，他们只是希望修正CVS。他们决定Subversion应符合CVS的特性，并保留相同的开发模型，但不再重复CVS的一些显著缺陷。尽管Subversion并不需要成为CVS的完全替代品，但它应该与CVS保持足够的相似性，以使CVS用户可以轻松的转移到Subversion上。
经过14个月的编码，2001年8月31日，Subversion能够“自己管理自己”了，开发者停止使用CVS保存Subversion的代码，而使用Subversion本身。
虽然CollabNet启动了这个项目，并且一直提供了大量的工作支持（它为一些全职的Subversion开发者提供薪水），但Subversion像其它许多开源项目一样，被松散的、透明的规则管理着，这样的规则激励着知识界的精英们。CollabNet的版权许可证完全符合Debian的自由软件方针。也就是说，任何人都可以根据自己的意愿自由的下载、修改和重新发布Subversion，不需要CollabNet或其他人的授权。
在讲解Subversion为版本控制领域带来的特性时，我们会经常通过Subversion对CVS的改进进行说明。如果不熟悉CVS，了解所有Subversion的特性会有一定的困难。而如果根本就不熟悉版本控制，你就只有干瞪眼的份儿了。因此，最好首先阅读一下第 1 章 基本概念，这一章简单介绍了一些版本控制的基本思想和概念。
Subversion支持：
- 版本化的目录
CVS只能跟踪单个文件的变更历史，但是Subversion实现的“虚拟”版本化文件系统则可以跟踪目录树的变更。在Subversion中，文件和目录都是版本化的。
- 真实的版本历史
由于只能跟踪单个文件的变更，CVS无法支持如文件拷贝和改名这些常见的操作—这些操作改变了目录的内容。同样，在CVS中，一个目录下的文件只要名字相同即拥有相同的历史，即使这些同名文件在历史上毫无关系。而在Subversion中，可以对文件或目录进行增加、拷贝和改名操作，也解决了同名而无关的文件之间的历史联系问题。
- 原子提交
一系列相关的更改，要么全部提交到版本库，要么一个也不提交。这样用户就可以将相关的更改组成一个逻辑整体，防止出现只有部分修改提交到版本库的情况。
- 版本化的元数据
每一个文件和目录都有自己的一组属性—键和它们的值。可以根据需要建立并存储任何键/值对。和文件本身的内容一样，属性也在版本控制之下。
- 可选的网络层
Subversion在版本库访问的实现上具有较高的抽象程度，利于人们实现新的网络访问机制。Subversion可以作为一个扩展模块嵌入到Apache之中。这种方式在稳定性和交互性方面有很大的优势，可以直接使用服务器的成熟技术—认证、授权和传输压缩等。此外，Subversion自身也实现了一个轻型的，可独立运行的服务器软件。这个服务器使用了一个自定义协议，可以轻松的用SSH封装。
- 一致的数据操作
Subversion用一个二进制差异算法描述文件的变化，对于文本（可读）和二进制（不可读）文件其操作方式是一致的。这两种类型的文件压缩存储在版本库中，而差异信息则在网络上双向传递。
- 高效的分支和标签操作
在Subversion中，分支与标签操作的开销与工程的大小无关。Subversion的分支和标签操作用只是一种类似于硬链接的机制拷贝整个工程。因而这些操作通常只会花费很少且相对固定的时间。
- 可修改性
Subversion没有历史负担，它以一系列优质的共享C程序库的方式实现，具有定义良好的API。这使得Subversion非常容易维护，和其它语言的互操作性很强。
图 1 “Subversion 的架构”给出了Subversion设计总体上的“俯视图”。
图中的一端是保存所有版本数据的Subversion版本库，另一端是Subvesion的客户程序，管理着所有版本数据的本地影射（称为“工作拷贝”），在这两极之间是各种各样的版本库访问（RA）层，某些使用电脑网络通过网络服务器访问版本库，某些则绕过网络服务器直接访问版本库。
安装好的Subversion由几个部分组成，本节将简单的介绍一下这些组件。下文的描述或许过于简略，不易理解，但不用担心，本书后面的章节中会用更多的内容来详细阐述这些组件。
- svn
命令行客户端程序。
- svnversion
此工具用来显示工作拷贝的状态（用术语来说，就是当前项目的修订版本）。
- svnlook
直接查看Subversion版本库的工具。
- svnadmin
建立、调整和修复Subversion版本库的工具。
- svndumpfilter
过滤Subversion版本库转储数据流的工具。
- mod_dav_svn
Apache HTTP服务器的一个插件，使版本库可以通过网络访问。
- svnserve
一个单独运行的服务器程序，可以作为守护进程或由SSH调用。这是另一种使版本库可以通过网络访问的方式。
- svnsync
一个通过网络增量镜像版本库的程序。
如果已经正确完成了Subversion的安装，我们就可以开始我们的学习之旅了。在后面的两章中，我们将讲解如何使用Subversion的客户端程序svn。