所有版本控制系统都必须解决同一个基本问题：系统如何允许用户共享信息，但又防止他们意外地踩到彼此的脚趾？用户很容易意外地覆盖彼此在仓库中的更改。

考虑 图 2.2，“要避免的问题” 中所示的场景。假设我们有两个同事，Harry 和 Sally。他们都决定同时编辑同一个仓库文件。如果 Harry 首先将他的更改保存到仓库，那么（片刻之后）Sally 可能会意外地用她自己的新版本的文件覆盖他的更改。虽然 Harry 的文件版本不会永远丢失（因为系统会记住每一次更改），但 Harry 所做的任何更改 不会 出现在 Sally 的较新版本的文件中，因为她从一开始就没有看到 Harry 的更改。Harry 的工作仍然实际上丢失了——或者至少在文件的最新版本中缺失——而且很可能是意外发生的。这绝对是我们想要避免的情况！

图 2.2. 要避免的问题

许多版本控制系统使用 锁定-修改-解锁 模型来解决多个作者互相覆盖彼此工作的难题。在这个模型中，仓库一次只允许一个人更改文件。这种排他性策略使用锁来管理。Harry 必须在开始修改文件之前“锁定”它。如果 Harry 锁定了文件，那么 Sally 就无法锁定它，因此也无法对该文件进行任何更改。她所能做的就是读取文件，并等待 Harry 完成他的更改并释放他的锁。在 Harry 解锁文件后，Sally 可以通过锁定和编辑文件来轮流操作。 图 2.3，“锁定-修改-解锁解决方案” 演示了这个简单的解决方案。

图 2.3. 锁定-修改-解锁解决方案

锁定-修改-解锁模型的问题在于它有点限制，并且经常成为用户的障碍

Subversion、CVS 和其他版本控制系统使用 复制-修改-合并 模型作为锁定的替代方案。在这个模型中，每个用户的客户端都会联系项目仓库并创建一个个人 工作副本——仓库文件和目录的本地反映。然后，用户并行工作，修改自己的私有副本。最后，私有副本被合并到一个新的最终版本中。版本控制系统通常会协助合并，但最终由人类负责使其正确完成。

以下是一个例子。假设 Harry 和 Sally 都创建了同一个项目的副本，从仓库中复制。他们同时工作，并对他们副本中的同一个文件 A 进行更改。Sally 首先将她的更改保存到仓库。当 Harry 稍后尝试保存他的更改时，仓库会通知他他的文件 A 过期。换句话说，仓库中的文件 A 已经在他上次复制它之后发生了变化。因此，Harry 要求他的客户端将仓库中的任何新更改 合并 到他的文件 A 的工作副本中。很可能 Sally 的更改不会与他自己的更改重叠；因此，一旦他将这两组更改都集成在一起，他就会将他的工作副本保存回仓库。 图 2.4，“复制-修改-合并解决方案” 和 图 2.5，“复制-修改-合并解决方案（续）” 展示了这个过程。

图 2.4. 复制-修改-合并解决方案

图 2.5. 复制-修改-合并解决方案（续）

但是如果 Sally 的更改 确实 与 Harry 的更改重叠了呢？那该怎么办？这种情况被称为 冲突，通常不是什么大问题。当 Harry 要求他的客户端将最新的仓库更改合并到他的工作副本中时，他的文件 A 的副本会被标记为处于冲突状态：他将能够看到两组冲突的更改，并手动选择其中之一。请注意，软件无法自动解决冲突；只有人类能够理解并做出必要的明智选择。一旦 Harry 手动解决了重叠的更改——也许是在与 Sally 讨论之后——他就可以安全地将合并后的文件保存回仓库。

复制-修改-合并模型听起来可能有点混乱，但在实践中，它运行起来非常顺畅。用户可以并行工作，永远不会互相等待。当他们处理同一个文件时，事实证明他们的大多数并发更改都不会重叠；冲突很少见。而且解决冲突所需的时间远远少于锁定系统造成的损失时间。

最终，这一切都归结于一个关键因素：用户沟通。当用户沟通不畅时，语法和语义冲突都会增加。没有任何系统可以强制用户完美沟通，也没有任何系统可以检测到语义冲突。因此，没有必要被锁定的系统会以某种方式防止冲突的错误承诺所迷惑；在实践中，锁定似乎比其他任何事情都更能阻碍生产力。