Subversion 是一个免费/开源的 版本控制系统 (VCS)。也就是说，Subversion 管理文件和目录，以及随着时间的推移对它们所做的更改。这使您能够恢复数据的旧版本，或检查数据如何更改的历史记录。在这方面，许多人认为版本控制系统是一种 “时间机器。 ”
Subversion 可以在网络中运行，这使其能够被不同计算机上的用户使用。在某种程度上，各种用户能够从各自的位置修改和管理相同数据集的能力促进了协作。进度可以在没有单个通道的情况下更快地进行，所有修改都必须通过该通道进行。由于工作是版本化的，您不必担心质量是失去该通道的权衡 - 如果对数据进行了一些不正确的更改，只需撤消该更改即可。
一些版本控制系统也是 软件配置管理 (SCM) 系统。这些系统专门用于管理源代码树，并具有许多特定于软件开发的功能，例如，本机理解编程语言或提供用于构建软件的工具。但是，Subversion 不是这些系统之一。它是一个通用系统，可用于管理 任何 文件集合。对于您来说，这些文件可能是源代码 - 对于其他人来说，可能是从杂货店购物清单到数字视频混音等等。
如果您是正在考虑使用 Subversion 的用户或系统管理员，您应该首先问自己一个问题：“这对工作来说是合适的工具吗？” Subversion 是一个很棒的锤子，但要小心，不要把所有问题都看作钉子。
作为第一步，您需要确定您的目的是否需要版本控制。如果您需要存档文件的旧版本和目录，可能需要恢复它们，并检查它们如何随着时间推移而更改的日志，那么版本控制工具可以做到这一点。如果您需要与人员合作处理文档（通常通过网络）并跟踪谁做了哪些更改，版本控制工具也可以做到这一点。实际上，这就是为什么 Subversion 等版本控制工具在软件开发环境中如此经常被使用的原因 - 在开发团队中工作本质上是一种社会活动，其中对源代码文件的更改不断被讨论、进行、评估，甚至有时会被撤销。版本控制工具有助于这种协作。
使用版本控制也与成本相关。除非您可以将版本控制系统的管理外包给第三方，否则您将承担自行执行该管理的显而易见的成本。在日常使用数据时，您将无法像平常一样复制、移动、重命名或删除文件。相反，您必须通过版本控制系统执行所有这些操作。
即使假设您对版本控制系统提供的成本/效益权衡感到满意，您也不应该仅仅因为版本控制系统 可以 做您想做的事情而选择使用它。考虑一下您的需求是否可以通过其他工具更好地解决。例如，由于 Subversion 将数据复制到所有参与的协作者，因此常见的误用是将其视为通用分发系统。人们有时会使用 Subversion 分发大量照片、数字音乐或软件包。问题是，这种数据通常根本不会发生变化。集合本身会随着时间的推移而增长，但集合中的单个文件不会被更改。在这种情况下，使用 Subversion 是一种 “过度的行为。 ”[2] 有一些更简单的工具可以有效地复制数据 而无需 跟踪更改的开销，例如 rsync 或 unison。
一旦您确定需要版本控制解决方案，您会发现可用的选项很多。当 Subversion 最初被设计和发布时，版本控制的主要方法是 集中式版本控制 - 一个远程主存储库，其中包含版本化数据，单个用户在该数据版本历史记录的浅层副本上本地操作。Subversion 在其最初发布后迅速成为该版本控制领域的领先者，赢得了广泛的采用，取代了许多旧版本控制系统的安装。它今天仍然保持着这一突出地位。
但是，从那时起发生了很多变化。自 Subversion 项目开始以来，一种称为 分布式版本控制 的更新版本控制方法也赢得了广泛的关注和采用。Git (http://git.js.cn/) 和 Mercurial (https://www.mercurial-scm.org/) 等工具已跃居分布式版本控制系统 (DVCS) 领域的最前沿。分布式版本控制利用高速网络连接和低存储成本的日益普及，提供了一种与集中式模型在关键方面不同的方法。首先也是最明显的是，没有远程的集中存储库来存放版本化数据。相反，每个用户都保留并操作非常深层的本地版本历史记录数据存储库，从某种意义上说，它是完整的。协作仍然存在，但通过直接在用户本地数据存储库之间交换对版本化项所做的更改集合来实现，而不是通过集中的主数据存储库。实际上，任何对项目的版本化数据的规范 “主” 源的表面迹象都只是约定俗成，是该项目中各种协作者赋予的一种状态。
每种版本控制方法都有其优缺点。DVCS 工具带来的两个最大好处可能是日常操作的惊人性能（因为主数据存储库是本地保存的）以及对分支之间合并的更强大支持（因为合并算法是 DVCSes 工作方式的核心）。缺点是分布式版本控制本质上是一个更复杂的模型，这可能会对舒适的协作造成不可忽视的挑战。此外，DVCS 工具之所以能够很好地完成它们的工作，部分原因是用户无法控制集中式系统自由提供的某些程度上的控制 - 实现基于路径的访问控制，灵活地更新或回溯单个版本化数据项等等。幸运的是，许多明智的组织已经发现，这不需要成为一场宗教辩论，Subversion 和 Git 等 DVCS 工具可以在组织内和谐地使用，每个工具都服务于最适合该工具的目的。
唉，这本书是关于 Subversion 的，所以我们不会尝试对 Subversion 和其他工具进行全面比较。有权选择版本控制系统的读者应鼓励研究可用的选项，并做出对自己和他们的同事最有效的决定。如果这样做之后，Subversion 是您选择的工具，那么接下来的章节中 有很多 关于如何成功使用它的详细信息！
2000 年初，CollabNet, Inc.（现称为 Digital.ai，https://digital.ai）开始寻找开发人员来编写 CVS 的替代品。CollabNet 提供了一个名为 CollabNet Enterprise Edition (CEE) 的协作软件套件，[3] 其中一个组件是版本控制。尽管 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 让他的雇主红帽软件公司基本上将他捐赠给该项目，时间不限。CollabNet 聘请了 Karl 和 Ben Collins-Sussman，详细的设计工作于 2000 年 5 月开始。在 Brian Behlendorf 和 Jason Robbins（来自 CollabNet）以及 Greg Stein（当时是一名参与 WebDAV/DeltaV 规范过程的独立开发人员）的一些推动下，Subversion 迅速吸引了活跃的开发者社区。事实证明，许多人遇到了与 CVS 相同的令人沮丧的经历，并欣然抓住机会最终解决这个问题。
最初的设计团队确定了一些简单的目标。他们不想在版本控制方法论方面开拓新的领域，他们只是想修复 CVS。他们决定 Subversion 将与 CVS 的功能相匹配，并保留相同的开发模型，但不会复制 CVS 最明显的缺陷。尽管它不需要成为 CVS 的直接替代品，但它应该足够相似，以至于任何 CVS 用户都可以轻松地进行切换。
经过 14 个月的编码，Subversion 在 2001 年 8 月 31 日开始 “自托管。 ” 也就是说，Subversion 开发人员停止使用 CVS 来管理 Subversion 自己的源代码，而是开始使用 Subversion。
虽然 CollabNet 发起了这个项目，并且仍然为大部分工作提供资金（它支付了几位全职 Subversion 开发人员的薪水），但 Subversion 的运行方式与大多数开源项目类似，由一套松散透明的规则管理，这些规则鼓励精英制度。2009 年，CollabNet 与 Subversion 开发人员合作，旨在将 Subversion 项目整合到 Apache 软件基金会 (ASF)，该基金会是世界上最知名的开源项目集合之一。Subversion 的技术根源、社区优先事项和开发实践与 ASF 完美契合，ASF 的许多成员已经是活跃的 Subversion 贡献者。2010 年初，Subversion 完全被 ASF 的顶级项目家族采用，将其网络资源迁移到 http://subversion.org.cn，并更名为 “Apache Subversion”.
图 1，“Subversion 架构” 说明了 Subversion 设计的 “高空鸟瞰” 视图。
一端是 Subversion 仓库，它保存着所有版本化的数据。另一端是您的 Subversion 客户端程序，它管理着这些版本化数据的本地镜像。在这两端之间，通过仓库访问 (RA) 层有多条路线，其中一些路线跨越计算机网络并通过网络服务器访问仓库，而另一些路线则完全绕过网络直接访问仓库。
Subversion 安装后，包含许多不同的部分。以下是您获得内容的快速概述。如果您对简要说明感到困惑，请不要担心——本书中还有 大量 页面专门用于消除这种困惑。
- svn
-
命令行客户端程序
- svnversion
-
用于报告工作副本状态（以当前项目的修订版本表示）的程序
- svnlook
-
用于直接检查 Subversion 仓库的工具
- svnadmin
-
用于创建、调整或修复 Subversion 仓库的工具
- mod_dav_svn
-
Apache HTTP Server 的插件模块，用于通过网络将您的仓库提供给其他人
- svnserve
-
一个自定义的独立服务器程序，可以作为守护进程运行，也可以由 SSH 调用；另一种通过网络将您的仓库提供给其他人的方式
- svndumpfilter
-
用于过滤 Subversion 仓库转储流的程序
- svnsync
-
用于将一个仓库增量镜像到另一个仓库的程序
- svnrdump
-
用于通过网络执行仓库历史记录转储和加载的程序
- svnmucc
-
用于在单个提交中执行多个基于仓库 URL 的操作，无需使用工作副本的程序
本书的第一版于 2004 年由 O'Reilly Media 出版，当时 Subversion 刚刚发布 1.0 版本。从那时起，Subversion 项目一直在发布软件的新主要版本。以下是 Subversion 1.0 版本之后主要新变化的简要概述。请注意，这不是完整的列表；有关完整详细信息，请访问 Subversion 网站 http://subversion.org.cn。
- Subversion 1.1（2004 年 9 月）
-
1.1 版本引入了 FSFS，一种用于仓库的平面文件仓库存储选项。虽然 Berkeley DB 后端仍然被广泛使用和支持，但 FSFS 由于其低进入门槛和最少的维护需求，已成为新建仓库的默认选择。该版本还增加了对将符号链接置于版本控制下的功能，对 URL 进行自动转义以及本地化的用户界面。
- Subversion 1.2（2005 年 5 月）
-
1.2 版本引入了对创建服务器端文件锁的功能，从而使对某些资源的提交访问序列化。虽然 Subversion 仍然是一个根本上的并发版本控制系统，但某些类型的二进制文件（例如艺术资产）无法合并在一起。锁定功能满足了对版本化和保护此类资源的需求。随着锁定的推出，还带来了完整的 WebDAV 自动版本控制实现，允许将 Subversion 仓库挂载为网络文件夹。最后，Subversion 1.2 开始使用一种新的、更快的二进制差异算法来压缩和检索文件的旧版本。
- Subversion 1.3（2005 年 12 月）
-
1.3 版本为 svnserve 服务器带来了基于路径的授权控制，与以前仅在 Apache 服务器中发现的功能相匹配。但是，Apache 服务器本身获得了一些新的日志记录功能，Subversion 对其他语言的 API 绑定也取得了长足进步。
- Subversion 1.4（2006 年 9 月）
-
1.4 版本引入了一个全新的工具——svnsync——用于通过网络进行单向仓库复制。工作副本元数据的很大一部分进行了修改，不再使用 XML（从而提高了客户端速度），而 Berkeley DB 仓库后端获得了在服务器崩溃后自动恢复自身的功能。
- Subversion 1.5（2008 年 6 月）
-
1.5 版本的完成时间比之前的版本要长得多，但其最引人注目的功能是巨大的：对分支和合并进行半自动跟踪。这对用户来说是一个巨大的福音，它将 Subversion 的功能远远超越了 CVS，并跻身于 Perforce 和 ClearCase 等商业竞争对手的行列。Subversion 1.5 还引入了一系列以用户为中心的功能，例如交互式解决文件冲突、稀疏检出、客户端管理变更列表、用于外部定义的强大新语法以及对 svnserve 服务器的 SASL 身份验证支持。
- Subversion 1.6（2009 年 3 月）
-
1.6 版本通过引入树冲突，使分支和合并更加健壮，并对一些现有功能进行了改进：更多交互式冲突解决选项；针对稀疏检出的去压缩和完全排除支持；基于文件的外部定义；以及为 svnserve 提供类似于 mod_dav_svn 提供的操作日志记录支持。此外，命令行客户端引入了用于引用 Subversion 仓库 URL 的新快捷方式语法。
- Subversion 1.7（2011 年 10 月）
-
1.7 版本主要是为了交付对现有 Subversion 组件进行的两次重大管道改造。其中最大、影响最大的变化被称为 “WC-NG”——对 libsvn_wc 工作副本管理库进行了彻底的重写。第二个变化是引入了更简洁的 Subversion 客户端/服务器交互 HTTP 协议。Subversion 1.7 还提供了一些额外的功能、许多错误修复以及一些显着的性能改进。
- Subversion 1.8（2013 年 6 月）
-
在 1.8 版本中，Subversion 的客户端现在可以更彻底地跟踪重命名的文件和目录，其 svn merge 命令变得足够智能，可以使
--reintegrate选项变得不再必要。某些新的版本化属性值可以从父目录继承。此功能现在允许仓库为自动属性设置和可忽略文件模式指定默认值，从而在该仓库的用户群中实现一致性，而以前必须通过社会方式进行管理。还有一个新的内置命令行文件合并工具，用于交互式冲突解决。与往常一样，Subversion 1.8 包含许多其他功能、缺陷修复以及行为和性能方面的改进。
