版本控制系统（或修订控制系统）是一种跟踪文件和目录随时间变化的增量版本（或修订）的系统。当然，仅仅跟踪用户（或一组用户）文件和目录的各种版本本身并不是很有趣。使版本控制系统变得有用的事实是，它允许您探索导致每个版本的更改，并促进任意版本的恢复。
在本节中，我们将介绍一些相当高级的版本控制系统组件和概念。我们将把讨论限制在现代版本控制系统——在当今互联的世界中，几乎没有理由承认无法跨广域网工作的版本控制系统。
版本控制系统的核心是仓库，它是该系统数据的中心存储库。仓库通常以 文件系统树 的形式存储信息——一个文件和目录的层次结构。任何数量的 客户端 都可以连接到仓库，然后读取或写入这些文件。通过写入数据，客户端使信息对其他人可用；通过读取数据，客户端从其他人接收信息。 图 1.1，"典型的客户端/服务器系统" 说明了这一点。
为什么这很有趣？到目前为止，这听起来像是典型文件服务器的定义。事实上，仓库 是 一种文件服务器，但它不是你通常见到的那种。使仓库特殊的是，当仓库中的文件发生更改时，仓库会记住这些文件的每个版本。
当客户端从仓库读取数据时，它通常只看到文件系统树的最新版本。但使版本控制客户端变得有趣的是，它还具有从仓库请求文件系统先前状态的能力。版本控制客户端可以询问诸如 “上周三这个目录包含什么内容？” 和 “谁是最后修改此文件的人，他做了哪些更改？” 的历史问题。这些问题是任何版本控制系统的核心。
版本控制系统的价值在于它跟踪文件和目录的版本，但软件宇宙的其余部分并不以 “文件和目录的版本” 运行。大多数软件程序只了解如何操作特定类型文件的 单个 版本。那么，版本控制用户如何以具体的方式与包含多个文件版本的抽象（而且通常是远程的）仓库进行交互呢？他的或她的文字处理软件、演示软件、源代码编辑器、网页设计软件或其他一些程序——所有这些都使用简单数据文件的货币——如何获得对这些文件的访问权？答案在于称为 工作副本 的版本控制构造。
工作副本从字面上来说，是用户 VCS 管理数据的特定版本的本地副本，用户可以在该副本上自由工作。工作副本[5] 对其他软件来说就像任何其他充满文件的本地目录一样，因此这些程序不需要 “版本控制感知” 才能从这些数据中读取和写入这些数据。管理工作副本并将对内容所做的更改与仓库进行通信的任务完全落在了版本控制系统的客户端软件身上。
如果版本控制系统的首要任务是跟踪数字信息随时间的各种版本，那么任何现代版本控制系统的次要任务是启用协作编辑和共享这些数据。但不同的系统使用不同的策略来实现这一点。理解这些不同的策略很重要，原因有以下几点。首先，它将帮助您比较和对比现有的版本控制系统，以防您遇到类似于 Subversion 的其他系统。除此之外，它还有助于您更有效地使用 Subversion，因为 Subversion 本身支持几种不同的工作方式。
所有版本控制系统都必须解决同一个基本问题：系统将如何允许用户共享信息，但防止他们不小心踩到彼此的脚？用户很容易不小心在仓库中覆盖彼此的更改。
考虑 图 1.2，"要避免的问题" 中所示的场景。假设我们有两名同事，哈里和莎莉。他们都决定同时编辑同一个仓库文件。如果哈里先将他的更改保存到仓库中，那么莎莉可能（几分钟后）不小心用她自己的新版本文件覆盖他的更改。虽然哈里版本的这个文件不会永远丢失（因为系统会记住每个更改），但哈里所做的任何更改 不会 出现在莎莉的较新版本的这个文件中，因为她最初没有看到哈里的更改。哈里的工作仍然实际上丢失了——或者至少在该文件的最新版本中丢失了——而且可能是意外的。这绝对是我们想要避免的情况！
许多版本控制系统使用 锁定-修改-解锁 模型来解决多个作者互相覆盖彼此工作的問題。在这个模型中，仓库一次只允许一个人更改一个文件。这种排他性策略使用锁定来管理。哈里必须 “锁定” 一个文件才能开始对其进行更改。如果哈里锁定了一个文件，莎莉就不能再锁定它，因此不能对该文件进行任何更改。她能做的只是读取该文件并等待哈里完成他的更改并释放他的锁定。在哈里解锁文件之后，莎莉就可以通过锁定和编辑文件来轮流进行。 图 1.3，"锁定-修改-解锁解决方案" 演示了这个简单的解决方案。
锁定-修改-解锁模型的问题在于它有点限制性，而且经常成为用户的障碍
-
锁定可能会导致管理问题。 有时哈里会锁定一个文件，然后忘记它。同时，由于莎莉仍在等待编辑该文件，她的手被束缚了。然后哈里去度假了。现在莎莉必须让管理员释放哈里的锁定。最终，这种情况会导致很多不必要的延迟和浪费时间。
-
锁定可能会导致不必要的串行化。 如果哈里正在编辑文本文件的开头，而莎莉只是想编辑同一文件的结尾怎么办？这些更改根本没有重叠。他们可以很容易地同时编辑该文件，并且不会造成重大损害，假设更改已正确合并在一起。在这种情况下，他们不需要轮流进行。
-
锁定可能会造成一种虚假的安全感。 假设哈里锁定并编辑文件 A，而莎莉同时锁定并编辑文件 B。但是，如果 A 和 B 相互依赖，并且对每个文件所做的更改在语义上不兼容怎么办？突然，A 和 B 不再一起工作了。锁定系统无力阻止问题——但它在某种程度上提供了一种虚假的安全感。哈里和莎莉很容易想象，通过锁定文件，每个人都开始了安全、隔离的任务，因此他们不必一开始就讨论他们不兼容的更改。锁定经常成为真正沟通的替代品。
Subversion、CVS 和许多其他版本控制系统使用 复制-修改-合并 模型作为锁定的替代方案。在这个模型中，每个用户的客户端都会联系项目仓库并创建一个个人工作副本。然后，用户可以同时独立地工作，修改他们的私人副本。最后，私人副本被合并到一个新的最终版本中。版本控制系统通常会协助合并，但最终，人类负责正确地进行合并。
以下是一个示例。假设哈里和莎莉都从仓库中创建了同一个项目的副本。他们同时工作，并对他们副本中的同一个文件 A 进行更改。莎莉首先将她的更改保存到仓库中。当哈里稍后尝试保存他的更改时，仓库会告诉他他的文件 A 已过期。换句话说，仓库中的文件 A 自他上次复制它以来发生了某种更改。因此，哈里要求他的客户端将仓库中的任何新更改 合并 到他工作副本的 A 文件中。有可能莎莉的更改与他自己的更改没有重叠；一旦他将两组更改整合在一起，他就会将他的工作副本保存回仓库中。 图 1.4，"复制-修改-合并解决方案" 和 图 1.5，"复制-修改-合并解决方案（续）" 展示了这个过程。
但如果莎莉的更改 确实 与哈里的更改重叠呢？那该怎么办？这种情况称为 冲突，这通常不是什么大问题。当哈里要求他的客户端将最新的仓库更改合并到他的工作副本时，他的 A 文件副本以某种方式被标记为处于冲突状态：他将能够看到两组冲突的更改并手动选择它们。请注意，软件无法自动解决冲突；只有人类能够理解并做出必要的智能选择。一旦哈里手动解决了重叠的更改——可能是在与莎莉讨论之后——他就可以安全地将合并后的文件保存回仓库中。
复制-修改-合并模型可能听起来有点混乱，但在实践中，它运行得非常顺利。用户可以并行工作，永远不会互相等待。当他们在同一个文件上工作时，事实证明他们大多数并发更改根本没有重叠；冲突很少见。而且，解决冲突所需的时间通常远远少于锁定系统所浪费的时间。
归根结底，一切都取决于一个关键因素：用户沟通。当用户沟通不畅时，语法和语义冲突都会增加。任何系统都无法强迫用户完美沟通，也无法检测语义冲突。因此，不要被一种错误的安全感所迷惑，认为锁定系统可以阻止冲突；实际上，锁定似乎比其他任何事情都更能阻碍生产力。