Subversion 是一个免费/开源的版本控制系统。也就是说，Subversion 随着时间的推移管理文件和目录以及对它们的更改。这使您可以恢复数据的旧版本或检查数据更改的历史记录。在这方面，许多人将版本控制系统视为一种“时间机器”。
Subversion 可以跨网络运行，这使得它可以被不同计算机上的人使用。在某种程度上，不同的人从各自的位置修改和管理同一组数据的能力促进了协作。进度可以更快，而无需单个渠道来进行所有修改。而且由于工作是版本化的，您不必担心失去该渠道会导致质量下降——如果对数据进行了不正确的更改，只需撤销该更改即可。
一些版本控制系统也是软件配置管理 (SCM) 系统。这些系统专门用于管理源代码树，并具有许多针对软件开发的特定功能，例如，本机理解编程语言或提供用于构建软件的工具。但是，Subversion 不是这些系统之一。它是一个通用系统，可用于管理任何文件集合。对于您来说，这些文件可能是源代码——对于其他人来说，可以是任何东西，从杂货店购物清单到数字视频混音等等。
在 2000 年初，CollabNet, Inc. (http://www.collab.net) 开始寻找开发者来编写 CVS 的替代品。CollabNet 提供了一个名为 CollabNet Enterprise Edition (CEE) 的协作软件套件，其中一个组件是版本控制。虽然 CEE 使用 CVS 作为其初始版本控制系统，但 CVS 的局限性从一开始就显而易见，CollabNet 知道它最终必须找到更好的东西。不幸的是，CVS 已成为开源世界中的事实上的标准，主要是因为至少在免费许可下没有更好的东西。因此，CollabNet 决定从头开始编写一个新的版本控制系统，保留 CVS 的基本思想，但没有其错误和错误功能。
2000 年 2 月，他们联系了 Karl Fogel，他是使用 CVS 进行开源开发（Coriolis，1999）的作者，并询问他是否愿意参与这个新项目。巧合的是，当时 Karl 已经与他的朋友 Jim Blandy 讨论了新版本控制系统的设计。1995 年，两人共同创办了 Cyclic Software 公司，该公司提供 CVS 支持合同，尽管他们后来出售了这家公司，但他们仍然每天在工作中使用 CVS。他们对 CVS 的沮丧让 Jim 认真考虑了管理版本化数据的更好方法，而且他已经不仅想出了“Subversion”这个名字，还想出了 Subversion 数据存储的基本设计。当 CollabNet 打电话时，Karl 立即同意参与该项目，而 Jim 让他的雇主 Red Hat Software 基本上将他捐赠给该项目，期限不确定。CollabNet 聘请了 Karl 和 Ben Collins-Sussman，详细的设计工作于 5 月开始。在 CollabNet 的 Brian Behlendorf 和 Jason Robbins 以及 Greg Stein（当时是 WebDAV/DeltaV 规范流程中积极参与的独立开发者）的帮助下，Subversion 迅速吸引了一群活跃的开发者。事实证明，许多人对 CVS 都有相同的令人沮丧的体验，并欢迎有机会最终对此采取措施。
最初的设计团队确定了一些简单的目标。他们不想在版本控制方法上开拓新天地，他们只是想修复 CVS。他们决定 Subversion 将匹配 CVS 的功能，并保留相同的开发模型，但不会复制 CVS 最明显的缺陷。虽然它不需要成为 CVS 的直接替代品，但它应该足够相似，以便任何 CVS 用户都可以轻松切换。
经过 14 个月的编码，Subversion 于 2001 年 8 月 31 日成为“自托管”。也就是说，Subversion 开发人员停止使用 CVS 来管理 Subversion 自己的源代码，而是开始使用 Subversion。
虽然 CollabNet 启动了该项目，并且仍然资助了大部分工作（它支付了几名全职 Subversion 开发人员的薪水），但 Subversion 像大多数开源项目一样运行，受一套松散、透明的规则管理，这些规则鼓励精英统治。CollabNet 的版权许可完全符合 Debian 自由软件准则。换句话说，任何人都可以随意下载、修改和重新分发 Subversion；无需获得 CollabNet 或任何其他人的许可。
在讨论 Subversion 带来的版本控制功能时，通常以它们如何改进 CVS 的设计来进行描述。如果您不熟悉 CVS，您可能无法理解所有这些功能。如果您完全不熟悉版本控制，除非您首先阅读第 1 章，基本概念，其中我们对版本控制进行了简要介绍，否则您可能会感到迷惑不解。
Subversion 提供
- 目录版本控制
CVS 仅跟踪单个文件的历史记录，但 Subversion 实现了一个“虚拟”版本化文件系统，它随着时间的推移跟踪整个目录树的更改。文件和目录都是版本化的。
- 真正的版本历史
由于 CVS 限于文件版本控制，因此诸如复制和重命名之类的操作（这些操作可能发生在文件上，但实际上是对某些包含目录的内容的更改）在 CVS 中不受支持。此外，在 CVS 中，您无法用相同名称的某些新事物替换版本化文件，而不会使新项目继承旧文件（可能是完全不相关的）的历史记录。使用 Subversion，您可以添加、删除、复制和重命名文件和目录。每个新添加的文件都从它自己全新的历史记录开始。
- 原子提交
一组修改要么完全进入存储库，要么完全不进入。这使开发人员能够构建和提交更改作为逻辑块，并防止在仅将更改集的一部分成功发送到存储库时可能出现的问题。
- 版本化元数据
每个文件和目录都有一组与之关联的属性——键及其值。您可以创建和存储您想要的任何任意键/值对。属性随时间推移进行版本控制，就像文件内容一样。
- 网络层的选择
Subversion 对存储库访问有一个抽象的概念，这使得人们可以轻松地实现新的网络机制。Subversion 可以作为扩展模块插入 Apache HTTP Server。这使 Subversion 在稳定性和互操作性方面具有很大优势，并可以立即访问该服务器提供的现有功能——身份验证、授权、线路压缩等等。还提供了一个更轻量级的独立 Subversion 服务器进程。此服务器使用自定义协议，可以轻松地通过 SSH 进行隧道传输。
- 一致的数据处理
Subversion 使用二进制差异算法来表达文件差异，该算法对文本（人类可读）和二进制（人类不可读）文件的作用相同。两种类型的文件都以相同的方式压缩存储在存储库中，差异以双向方式在网络上传输。
- 高效的分支和标记
分支和标记的成本不必与项目大小成正比。Subversion 通过简单地复制项目来创建分支和标记，使用类似于硬链接的机制。因此，这些操作仅需要很少的、恒定的时间。
- 可破解性
Subversion 没有历史包袱；它作为一组具有明确定义的 API 的共享 C 库来实现。这使得 Subversion 非常易于维护，并且可以被其他应用程序和语言使用。
图 1，“Subversion 的架构” 说明了 Subversion 设计的“一英里高”视图。
一端是 Subversion 存储库，它保存所有版本化数据。另一端是您的 Subversion 客户端程序，它管理该版本化数据的部分的本地反映（称为“工作副本”）。在这两端之间，有通过各种存储库访问 (RA) 层的多个路由。其中一些路由跨越计算机网络并通过网络服务器，然后访问存储库。另一些绕过网络完全直接访问存储库。
安装 Subversion 后，它会包含许多不同的部分。以下是您获得内容的快速概述。如果简短的描述让您感到困惑，请不要惊慌——本书中还有很多页专门用于消除这种困惑。
- svn
命令行客户端程序。
- svnversion
一个用于报告工作副本状态（以项目存在的修订版表示）的程序。
- svnlook
用于直接检查 Subversion 存储库的工具。
- svnadmin
用于创建、调整或修复 Subversion 存储库的工具。
- svndumpfilter
用于过滤 Subversion 存储库转储流的程序。
- mod_dav_svn
Apache HTTP Server 的插件模块，用于通过网络向他人提供您的存储库。
- svnserve
一个自定义的独立服务器程序，可以作为守护进程运行，也可以由 SSH 调用；另一种通过网络向他人提供存储库的方法。
- svnsync
用于将一个存储库增量镜像到另一个存储库的程序，通过网络完成。
假设您已正确安装 Subversion，那么您应该准备开始。接下来的两章将指导您使用 svn，Subversion 的命令行客户端程序。