A  project/Makefile
        ...
        Checked out revision 1.

    现在，我们在一个新的 project 目录下就有了仓库中一部分数据的一个私人副本了。你可以在本地工作副本上编辑某个文件，然后再将那些修改提交到仓库中。

        ?进入工作副本目录，修改文件内容；
        ?运行 svn diff 来检查你对文件的修改情况；
        ?运行 svn commit 来将新版本的文件提交到仓库中；
        ?运行 svn update 来使用仓库中最新的版本来更新你的本地工作副本。

    如果想知道我们可以对"本地工作副本"所作的事情，请参阅第三章――使用指南。
    这时，你可以选择是否让其他人通过网络访问你的仓库。你可以阅读第六章――服务器配置来学习不同的服务器程序和如何配置它们

 

第二章 基本概念
    本章是对 Subversion 的一个简短的介绍。如果你是使用版本控制工具的新手，这一章将非常适合你。我们先从版本控制的一般概念说起，接着会谈到 Subversion 底层的具体思想以及一些简单的案例。
    尽管在本章的案例中我们展示的是如何协同管理软件源代码，但请记住，Subversion 可以管理任何类型的文件集合，而并不仅限于源程序。
第二章 基本概念
    本章是对 Subversion 的一个简短的介绍。如果你是使用版本控制工具的新手，这一章将非常适合你。我们先从版本控制的一般概念说起，接着会谈到 Subversion 底层的具体思想以及一些简单的案例。
    尽管在本章的案例中我们展示的是如何协同管理软件源代码，但请记住，Subversion 可以管理任何类型的文件集合，而并不仅限于源程序。

2.1 仓库（The Repository）

    Subversion 是一个集中式的系统。它的核心是一个用来存放数据的中心仓库。中心仓库使用典型的文件和目录层次结构――树状结构来存储信息。许许多多的客户端可以连接到中心仓库，然后读取或者写入文件。客户端通过写文件来使其他人共享，也可以读取其它客户端所写入的文件。下面的图2.1描述了这样的一个典型的客户端/服务器系统模型。

               图2.1

    有趣的是，到此为止，这个仓库听起来像是一个典型的文件服务器。而且确实，仓库就是一种文件服务器，只是不是通常的那种。Subversion 仓库可以记录写入仓库的每一次更改。这些更改包括对每一个文件的每一次修改，甚至是对目录本身的修改，例如添加文件、删除文件和对文件和目录的重新编排。这些特性使得 Subversion 仓库与一般的文件服务器相比较为特殊。
    当一个客户端读取仓库中的数据时，他通常只能看到最新版本的文件目录。但是客户端同样可以读取文件和目录以前某个时刻的状态。例如，客户端可以这样做查询："上个星期三这个目录包含什么文件？"或者是"修改这个文件的最后一个人是谁？他做了什么修改？"。这类问题正是版本控制系统的核心：记录和跟踪数据的修改历史。

2.2 版本控制模型

    版本控制系统的核心任务是使得数据可以协作处理和共享。但是不同的系统使用不同的策略来达到这个目标。

2.2.1 文件共享的问题

    所有的版本控制系统都必须解决一个共同的基本问题：如何让用户来共享信息，并且还要避免他们不小心覆盖掉别人对仓库中数据作过的修改？毕竟，这种情况太容易发生了。
    让我们先来看看下面的图2.2 "要避免的问题"。假设我们有两个合作开发者：Harry 和 Sally。他们两个人在同一个时间决定对仓库中的同一个文件进行编辑。如果 Harry 先将他的修改保存到仓库中，那么可能在很短时间之后，Sally 会使用她的新版本文件覆盖掉仓库中该文件。由于系统记录了 Harry 对文件的修改，但是这些修改并没有出现在 Sally 的新版本文件中。这样，Harry 的工作实际上就丢掉了，或者说在最新版本的文件中漏掉了。这是我们一定要避免出现的情景。

    图2.2 要避免的问题

2.2.2 "锁定―修改―解锁" 方案

    许多版本控制系统都使用"锁定―修改―解锁"模型来解决这个问题。在这样一个系统中，仓库在一个特定的时刻只允许一个人对某个文件进行修改。首先，Harry 必须在修改文件之前"锁定"它。锁定一个文件很像是从图书馆借出一本书；如果 Harry 锁定了一个文件，那么 Sally 就不能对那个文件作任何修改了。如果 Sally 也试图锁定这个文件，仓库将禁止这项操作。她只能读取该文件，然后等待 Harry 完成他的修改并解锁文件。在 Harry 解锁那个文件之后，他的回合就结束了。这是轮到 Sally 来锁定和编辑文件。图2.3 简单的演示了这种方案。

    图2.3 "锁定―修改―解锁"方案

    这种方案的问题是它有一点过于严格了，经常会阻塞用户的使用：

    ?锁定可能会带来管理问题。有时 Harry 锁定了一个文件，但是随后却忘了这回事。同时，Sally 的任务却因为仍然在等待编辑那个文件而停滞不前。现在，Harry 去休假了。Sally 只能是去找管理员来释放 Harry 对这个文件的锁定。这种情况最终导致了项目不必要的延迟和宝贵时间的浪费。
    ?锁定可能导致不必要的串行工作。如果 Harry 要编辑一个文本文件的开头部分，而 Sally 只想编辑同一个文件的结尾部分，这些更改根本不会重叠和冲突。假设他们的修改可以很好的合并在一起，他们本可以同时对文件进行修改，而不会引起大的混乱。这种情况下并没有必要非得一个一个的串行工作。
    ?锁定可能会引起潜在的不安全性。假如，Harry 锁定了文件 A 进行编辑，而同时，Sally 则锁定了文件 B 进行编辑。但是假设文件 A 和 B 是互相依赖的两个文件，两人在两个文件上所作的改动是不兼容的。一下子，A 和 B 同时都不能工作了。锁定机制很难解决这个问题。Harry 和 Sally 很容易在锁定文件后就主观的认为已经获得了一个安全的、隔绝的任务，这样就导致了他们不可能尽早地讨论文件修改的兼容性问题。