前言

所有的版本控制系统都需要解决这样一个基础问题: 怎样让系统允许用户共享信息，而不会让他们因意外而互相干扰？版本库里意外覆盖别人的更改非常的容易。

** 文件共享的问题** 考虑这个情景，我们有两个共同工作者，Harry 和 Sally，他们想同时编辑版本库里的同一个文件，如果首先 Harry 保存它的修改，过了一会，Sally 可能凑巧用自己的版本覆盖了这些文件，Harry 的更改不会永远消失(因为系统记录了每次修改)，Harry 所有的修改不会出现在 Sally 的文件中，所以 Harry 的工作还是丢失了—至少是从最新的版本中丢失了—而且是意外的，这就是我们要明确避免的情况！

1. 需要避免的问题

共享文件存在的问题分析

2. 锁定-修改-解锁 方案

许多版本控系统使用 锁定-修改-解锁 模型来解决这个问题，这是一个简单的解决方案。在这种系统中，在同一时间版本库只允许一个用户修改一个文件。首先，Barry 必须在修改前 锁定 该文件。锁定文件有点像从图书馆结束; 如果 Harry 锁定了一个文件，那么 Sally 就修改该文件。如果她试图锁定该文件，版本库会拒绝这个请求。她只能读取这个文件，并等待 Harry 结束修改并释放文件锁。在 Harry 解锁文件后，他的任务就完成了，现在 Sally 可以接手工作 - 锁定并编辑文件。

锁定-修改-解锁 方案

锁定-修改-解锁模型有一点问题就是限制太多，经常会成为用户的障碍:

锁定可能导致管理问题。有时候 Harry 会锁住文件然后忘了此事，这就是说 Sally 一直等待解锁来编辑这些文件，她在这里僵住了。然后 Harry 去旅行了，现在 Sally 只好去找管理员放开锁，这种情况会导致不必要的耽搁和时间浪费。

锁定可能导致不必要的线性化开发。如果 Harry 编辑一个文件的开始，Sally 想编辑同一个文件的结尾，这种修改不会冲突，设想修改可以正确的合并到一起，他们可以轻松的并行工作而没有太多的坏处，没有必要让他们轮流工作。

锁定可能导致错误的安全状态。假设 Harry 锁定和编辑一个文件 A，同时 Sally 锁定并编辑文件 B，如果 A 和 B 互相依赖，这种变化是必须同时作的，这样 A 和 B 不能正确的工作了，锁定机制对防止此类问题将无能为力—从而产生了一种处于安全状态的假相。很容易想象 Harry 和 Sally 都以为自己锁住了文件，而且从一个安全，孤立的情况开始工作，因而没有尽早发现他们不匹配的修改。

3. 复制-修改-合并 方案

这儿有一个例子。比如说 Harry 和 Sally 参加同一个项目每人都有各自的工作副本，从同一个版本库复制出来的。他们同时工作，在自己的副本中修改同一个文件 A。Sally 先将她的更改保存到版本库中。 稍后，当 Harry 尝试提交他的更改时，版本库提示他的文件 A 已经过时。换句话说，自从他上次复制文件后，无论如何版本库中的文件 A 已经被修改了。所以 Harry 要用客户端程序将版本库中文件 A 的新更改 合并 到他的工作副本中。碰巧的是 Sally 的更改和他的不重合; 所以一旦他整合了两人的更改，他就可以把他的工作副本复制回版本库。

复制-修改-合并 方案

复制-修改-合并 方案(续)

但是如果 Sally 和 Harry 的修改重叠了该怎么办？这种情况叫做冲突，这通常不是个大问题，当 Harry 告诉他的客户端去合并版本库的最新修改到自己的工作副本时，他的文件 A 就会处于冲突状态: 他可以看到一对冲突的修改集，并手工的选择保留一组修改。需要注意的是软件不能自动的解决冲突，只有人可以理解并作出智能的选择，一旦 Harry 手工的解决了冲突(也许需要与 Sally 讨论)，他就可以安全的把合并的文件保存到版本库。

复制-修改-合并模型感觉是有一点混乱，但在实践中，通常运行的很平稳，用户可以并行的工作，不必等待别人，当工作在同一个文件上时，也很少会有重叠发生，冲突并不频繁，处理冲突的时间远比等待解锁花费的时间少。

最后，一切都要归结到一条重要的因素: 用户交流。当用户交流贫乏，语法和语义的冲突就会增加，没有系统可以强制用户完美的交流，没有系统可以检测语义上的冲突，所以没有任何证据能够承诺锁定系统可以防止冲突，实践中，锁定除了约束了生产力，并没有做什么事。

有一种情况下锁定-修改-解锁模型会更好，也就是你有不可合并的文件，例如你的版本库包含了图片，两个人同时编辑这个文件，没有办法将这两个修改合并，Harry 或 Sally 会丢失他们的修改。

4. Subversion 怎么做？

Subversion 缺省使用复制-修改-合并模型，大多数情况下可以满足你的需求。然而，Subversion 还是支持锁定，如果你有不可合并的文件，或者你只是想实行强制管理策略，Subversion 仍然会提供你需要的特性。

5. 工作副本怎样跟踪版本库

对于工作副本的每一个文件，Subversion 在管理目录 .svn/ 记录两项关键的信息:

每次版本的修订提交都是基于你工作的副本进行逻辑对比的

给定这些信息，通过与版本库通讯，Subversion 可以告诉我们工作文件是处与如下四种状态的那一种:

未修改且是当前的 文件在工作目录里没有修改，在工作版本之后没有修改提交到版本库。svn commit 操作不做任何事情，svn update 不做任何事情。

本地已修改且是当前的 工作副本已经修改，从基准版本之后没有修改提交到版本库。本地修改没有提交，因此 commit 会成功的提交，update 不做任何事情。

本地未修改且过时 这个文件在工作副本没有修改，但在版本库中已经修改了。这个文件应当更新到最新公共版本。commit 不做任何事情，update 将会更新工作副本到最新的版本。

本地已修改且过时 这个文件在工作副本和版本库中都被修改了。提交 该文件将会因为 过时 而失败。该文件应该先更新; 更新 命令将会尝试合并公共更改和本机更改。如果 Subversion 不能顺利的自动完成合并，则需要用户解决冲突。

以上是服务器更新没更新和用户本地更新没更新而产生的4种组合可能性，希望对你在SVN使用过程进行协作的时候有所帮助！