Subversion使用手册

1、Subversion使用手册配置Subversion版本控制选用Subversion，它对重构的支持比CVS要好。例如改名，原子提交等CVS无法支持的操作。下载Subversion的Win32自动安装包，安装至D:Subversion。安装包会自动添加Path等变量。建立D:SVNRepo文件夹，作为代码的根目录。可安装TortoiseSVN作为Client。执行命令：svnadmin create D:svnrepo或通过TortoiseSVN建立repo根目录。立即就可以使用client通过file:/d:/svnRepo来访问该目录。SVN有3种常用访问方式。通过file:/, svn:

2、/,http:/ 等不同的协议来访问。对于协作开发，这三种都可以胜任：如果在同一局域网内，可通过windows的文件共享协议来访问其他机器上的文件，例如file:/server/d/svnrepo。svn协议使用3690端口，如果防火墙无法打开端口，可与Apache整合使用http协议。采用svn协议的好处是安全性比较强，可任意更改服务监听端口。运行%SVN_HOME%binsvnserve d r d:svnrepo，即可按照daemon方式来运行一个后台进程，监听svn协议的请求。-r的作用是声明root目录。在linux下运行一个daemon进程非常简单，但是在windows中想让进程在

3、后台运行就需要做成服务才行。下载并安装SVN Service Wrapper，将svnserve包装为服务。执行：svnservice -install -d -r d:svnrepo，在控制面板->服务中手动开启。用TortoiseSVN浏览svn:/localhost/，注意要带上最后的“/”指明root才能正确访问。使用版本控制必须要进行权限控制，svn协议的权限控制可通过ssh来控制，访问协议则改为：svn+ssh:/localhost/，windows下这种方式需要安装ssh客户端。另一种简易的版本控制为使用passwd文件。修改%REPO_HOME%/conf/ svnser

4、ve.conf，包含如下几句：    general    # 指定匿名可读，授权后才可写入    anon-access = read    auth-access = write    # 指定密码文件为当前目录下passwd    password-db = passwdPasswd文件内容如下，用户名 = 密码：    users    user1

5、= 123456     Subversion的Eclipse插件为：Subclipse，对SVN支持比较完善。一般的操作均可胜任。Subclipse和TortoiseSVN结合使用能发挥更大的威力。相关网站 SVN官方网站 TortoiseSVN，很好的SVN客户端 SVN Service Wrapper SVN eclipse插件参考资料 中文的SVN资料http:/svnbook.red- Book: Version Control with SVN SVN for Windows中文安装指南 SVN Book中文翻译第一章 简 介

6、60;   版本控制是管理信息变更的一门艺术。版本控制工具早已经成为许多程序员的主要工具之一，特别是那些时常对软件代码作了微小的改动却隔了一天就撤销的程序员 们。但是版本控制软件的用途并不仅限于软件开发的领域。只要人们使用计算机来管理经常变更的信息，就需要使用版本控制工具。而这正是 Subversion 可以展示自己的地方。    本章是对 Subversion 的一个概括性的介绍：Subversion 是什么？它用来做什么？以及如何得到它。第一章 简 介    版本控制是管理信息变更的一门艺术。版本控制工具早已经

7、成为许多程序员的主要工具之一，特别是那些时常对软件代码作了微小的改动却隔了一天就撤销的程序员 们。但是版本控制软件的用途并不仅限于软件开发的领域。只要人们使用计算机来管理经常变更的信息，就需要使用版本控制工具。而这正是 Subversion 可以展示自己的地方。    本章是对 Subversion 的一个概括性的介绍：Subversion 是什么？它用来做什么？以及如何得到它。1.1 什么是 Subversion？    Subversion 是一个自由的、开放源码的版本控制系统。也就是说，它可以管理各个时刻的文件和目录。Subve

8、rsion 将文件存放在一个中心仓库（repository）中。这个仓库非常类似于一个普通的文件服务器，只是它还可以记录文件和目录曾经做过的每一次变更。这 样，我们就可以恢复旧版本中的数据或者是检查数据曾经做过怎样的改动。在这点上，许多人都将版本控制系统比作一种"时间机器"。    Subversion 的仓库可以通过网络来访问，允许不同的用户在不同的计算机上使用。而使不同的使用者能够在各自所在的位置修改和管理同一组数据将会在某种程度上促进协同工 作。由于不再将所有的修改工作都限制在一个"通道"上，项目的前进将更快速。而且因

9、为所作的工作都是被记录的，如果做出了什么错误的修改，只需要撤销就可 以了，而不用担心失去那个"通道"将会同时失去质量。    有些版本控制工具同时还是软件配置管理系统（SCM,Software Configuration Management System）。这些系统是针对管理源代码二设计的。它们有许多针对软件开发的特性，例如本身就可以识别程序设计语言的语法，或者是提供编译软件的工具。 然而，Subversion 并不是这样一个系统。它是一个通用的，可以管理任何计算机文件的系统。对你来说，可能是管理源代码，而对其他人来说，从购物清单到视频文件都

10、是可能的。1.2 Subversion 的历史    在2000年年初，CollabNet公司（） 就开始寻找开发人员来设计一个用以替代 CVS 的系统。CollabNet 公司当时正在提供一种叫做"SourceCast"的软件协作开发套件。其中的一个组件就是版本控制系统。虽然该系统最初是使用 CVS 作为版本控制组件的，但是 CVS 的局限性从从始至终就很明显。CollabNet 公司知道自己最终必须找到一个更好的替代品。但是很不幸，CVS 已经成为了开放源码领域中的事实上的标准。而很大一部分原因是因为找不到其他更好的系统。至少找不到更好的自

11、由软件。于是，CollabNet 公司决定从头设计一个版本控制系统。一个保留了 CVS 的基本思想，但是却没有缺陷的、有特色的版本控制系统。    2000年二月，他们联系到了 Open Source Development with CVS 一书的作者 Karl Fogel。并且邀请其加入这个新项目。很巧合的是，那时 Karl 已经和他的朋友 Jim Blandy 讨论过一套新的版本控制系统的设计。在1995年，他们两人曾经开办过一家公司 Cyclic Software。公司专门提供对 CVS 的支持服务。虽然他们后来卖掉了这项业务，但是仍然在每天的工作中使用

12、CVS 。在 CVS 上的挫败让 Jim 得以仔细的思考管理版本化数据的更好的方法。他不仅提出了"Subversion"的名字，同时还构思了 Subversion 中心仓库 Repository 的基础设计思路。所以当 CollabNet 征招时，Karl 几乎立刻就答应了参加项目。Jim 的雇主：RedHat Software 赞助了该项目，并且是不限期的。CollabNet 雇用了 Karl 和 Ben Collins-Sussman。详细的设计工作从当年五月开始。这里我们应该提到 CollabNet 的 Brian Behlendorf 和 Jason Robbins

13、 以及 Greg Stein （当时是活跃于 WebDAV/DeltaV 规范进程的独立开发者）。在他们的努力下，Subversion 很快就吸引了一批活跃的开发者。这正说明了许多人也曾在使用 CVS 中有过受挫折的经历。并且希望能够改变这种局面。    最初的设计团队决定了一些简单的目标。他们并不想在版本控制方法学中开辟新的天地，而是去修改 CVS。他们让 Subversion 来使用 CVS 的特性，并且保留相同的开发模型。但是他们将避开 CVS 的那些明显的缺陷。尽管 Subversion 并不需要设计的像一个 CVS 的潜移默化的替代品，它仍然应该设计的与

14、 CVS 很像，以便于 CVS 的用户可以毫不费力的切换过来。    在经过十四个月的编码之后，Subversion 于2001年8月进入"自测"阶段。也就是说，Subversion 的开发者们停止使用 CVS 来管理 Subversion 的代码，而取而代之的是 Subversion 自己。    当 CollabNet 启动项目，并且资助很大一部分工作时（公司为一部分全职的开发人员支付薪水），Subversion 同时也像其他的开放源码项目那样运行。项目由一种鼓励知识精英的松散的、透明的规则所支配。Collab

15、Net 的版权许可是完全遵从 Debian Free Software Guidelines 的。换句话说，任何人，如果他愿意的话，都可以自由的下载、修改和再次发行 Subversion；不需要从 CollabNet 或者任何人那里获得授权。    1.3 Subversion 的特色    当我们说起 Subversion 给版本控制系统领域带来什么特色时，最好是说说它对 CVS 的设计所作的改进。如果你不熟悉 CVS 的话，你可能不理解这里的某些特性。如果你对版本控制也不了解，最好去阅读一下第二章：基本概念。在第二章我们给出了对版

16、本控制的一般性的介绍。    Subversion 的特性：    目录控制        CVS 只能跟踪单个文件的历史，而 Subversion 实现了一个"虚拟"的受控文件系统，可以跟踪整个目录的变更。    真正的版本历史        由于 CVS 只限于记录文件的版本信息，像文件复制、重命名这样的操作它就不支持了。而这些操作是会实实在在

17、发生的，它们改变了所对应目录的内容。另外，在 CVS 中，如果你要用一个新文件来替换一个旧文件，并且两个文件名称相同的话，新文件将不得不继承旧文件的历史信息。即使是两个文件毫不相干也是这样。而在 Subversion 中，我们可以添加、删除、复制和重命名文件和目录。每一个新添加的文件都将拥有它自己的全新的历史信息。    原子化提交        一个变更集要么完整地被提交到仓库中，要么不做任何改变。这就允许开发人员把构造和提交修改当作一个逻辑上的整体来看。从而避免发生不完整地提交变更的情况。&

18、#160;   受控元数据        每一个文件和目录都有一个与其对应的属性集。你可以创建和保存任何"键名/键值"对来辅助文件本身。而这些属性就像文件内容一样，也是受版本控制系统控制的。    可选的网络层        Subversion 仓库的存取是一个抽象概念，有利于其他人实现新的网络访问机制。Subversion 可以作为一个外部模块插入到 Apache HTTP 服务器中

19、。这带给它在稳定性和互操作性方面的巨大优势。并且，Subversion 可以方便的利用 Apache 所提供的功能身份认证、权限管理、数据压缩等等。还有一个更轻量级的、单独的 Subversion 服务器叫做 Subversion server process。它引入了一种自定义的协议，可以很容易的使用 SSH 来建立通道。    一致的数据处理        Subversion 使用一种二进制的比较算法来表示文件之间的区别。它在文本文件（可阅读的）和二进制文件（不可阅读的）上是没有区别的。两

20、种类型的文件经过压缩后都同样的存放在仓库中，唯一的不同就是在网络上传输时的方法。    高效的分支和标记        分支和标记所带来的开销与项目的规模并没有直接的关系。Subversion 在创建分支和标记时使用类似"连接"的方式来复制项目。这样这些操作就只会耗费很少的通常是一个固定长度的时间。    扩展能力        Subversion 没有什么历史包袱；它是由一

21、组设计良好的 APIs实现的，包含在 C 的共享库中。这使得它很容易维护。也很容易被其他应用程序或语言使用。1.4 Subversion 的结构    图1.1，"Subversion 结构"描述了 Subversion 的一个很粗略的设计思路。    在系统的一端是存放着所有受控制数据的 Subversion 仓库。另一端是 Subversion 的客户端程序，管理着受控数据的一部分在本地的映射（称为"工作副本"）。在这两端之间，是通过各种仓库存取层（Repository Access,RA）

22、的多条通道。这些通道中，有些要使用计算机网络，再通过用来访问 Subversion 仓库的服务器。而有些则完全绕过了网络，直接对仓库进行操作。1.5 安装 Subversion    Subversion 是建立在一个叫做 APR（the Apache Portable Runtime library）的可移植运行库之上的。这也就是说，Subversion 可以运行在任何 Apache 服务器可以运行的操作系统之上：Windows、Linux，各种类型的 BSD、Mac OS X，Netware 以及其他的系统。    获得 Subv

23、ersion 的最简单的方法就是下载适合于你的操作系统的二进制软件包。Subversion 的站点（）一般会有这样的下载连接。通常来说，使用 Microsoft 操作系统的用户都可以得到有图形界面的安装程序。如果你使用的是类似 Unix 的操作系统的话，可以使用合适的打包分发系统（RPMs,DEBs,the ports tree等等）来获取。    同时，我们也可以直接使用源代码来编译 Subversion 。首先从它的官方站点下载最新的源代码发布。然后将其解压缩，按照 INSTALL 文件中的指示来编译系统。值得注意的是，一个发行版的源代码包中包含了许多工具，足

24、够你编译出一个可以和远程仓库连接的命令行工具（一般来说，有 apr、apr-util和一个初始的库）。但是 Subversion 中一些可选的部分则需要许多其他软件支持，例如 Berkeley DB 或者 Apache 。如果你要编译一个完全的系统的话，必须保证拥有 INSTALL 文件中提到的所有的软件包。而如果你想使用 Subversion 本身来获取代码的话，可以用你的客户端程序来得到最实时的源代码。在"获取源代码"一节中，我们将详细介绍有关情况。1.6 Subversion 的组件    一旦 Subversion 成功安装，我们将会看

25、到多个不同的应用程序。下面我们就来大致的看一下都有些什么组件。如果下面的这些简要说明让您感到迷惑的话，请先别着急。这本书还有许多页是专门为您消除这些困惑的。    svn        一个命令行式的客户端程序；    svnversion        报告本地工作副本状态（用当前档案的修订版本号表示）的程序；    svnadmin  

26、0;     用来创建、tweaking或者是修复仓库的工具；    svndumpfilter        A program for filtering Subversion repository dumpfile format streams.    mod_dav_svn        Apache 服务器的一个插件模块，用来使其他人可以通过网络访

27、问这个仓库；    svnserve        一个定制的、独立的 Subversion 服务程序。可作为一个驻留进程运行或者是由 SSH 调用。是使仓库可以被别人通过网络访问的另一种方法。    假如你正确的安装了 Subversion ，你应该可以开始使用了。接下来的两章将为你介绍 Subversion 的命令行工具 svn 的使用。1.7 快速入门    在我们当中，可能有些人不是很习惯从头到尾的阅读一本书来吸收新技术的方式。

28、这一节，我们将先行给出一个 Subversion 的使用介绍。心急的读者可以有机会通过实践来学习使用 Subversion 的技巧。同时，我们会告诉你到哪一章节可以找到相关的东西。    如果你对版本控制的整体概念很生疏，或者对 CVS 和 Subversion 使用的"复制修改合并"模型不熟悉的话，最好在往下读之前先去仔细看一下第二章基本概念。    注意：        在运行下面的例子之前，你必须保证下面两个工具可以正确运行： &

29、#160;          svn      命令行式的客户端程序；            svnadmin 管理工具；        同时还必须保证你的 svn 工具是针对 Berkeley DB 编译的。可以运行 svn -version 然后检查 ra_local 模块是

30、否可用来确认。如果没有这个模块，我们的客户端程序将无法访问 。    Subversion 将所有控制的数据都放在一个中央仓库中。所以首先，我们要创建一个这样的仓库：        $ svnadmin create /path/to/repos        $ ls /path/to/repos          conf/ 

31、; dav/  db/  format  hooks/  locks/  README.txt    这个命令创建了一个包含 Subversion 仓库的目录 /path/to/repos 。另外，这个目录必须创建在本地磁盘，而不能是在网络共享磁盘上。该目录主要包含了一些 Berkeley DB 的文件。在这个目录中，你是找不到所保存的文件的。在第五章仓库管理中可以找到更多的有关于仓库创建和维护的知识。    下一步，准备一个类似下面例子中的用来导入的文件、目录树。在树结构中，应该包含

32、三个顶层目录：branches、tags 和 trunk。具体的原因后面便会清楚了（参见第四章分支和合并）。        /tmp/project/branches/        /tmp/project/tags/        /tmp/project/trunk/         

33、0;              foo.c                        bar.c           

34、0;            Makefile                        .    一旦你准备好了目录树，就可以使用 svn import 命令来导入数据到仓库中了（参见"svn import"

35、;一节）：        $ svn import /tmp/project file:/path/to/repos -m "initial import"        Adding /tmp/project/branches        Adding /tmp/project/tags      

36、60; Adding /tmp/project/trunk        Adding /tmp/project/trunk/foo.c        Adding /tmp/project/trunk/bar.c        Adding /tmp/project/trunk/Makefile        .&#

37、160;       Committed revision 1.        $    现在，仓库中就有了整个目录树中的数据。注意，原始的 /tmp/project 目录并没有变化，Subversion 并不使用它。（实际上，如果你愿意的话，可以删除该目录）。为了开始操作仓库中的数据，我们需要先创建一个数据的"工作副本（working copy）"出来。这类似于一种私有的工作区。向 Subversion "

38、;check out"（借出）一份仓库中 trunk 目录的工作副本：        $ svn checkout file:/path/to/repos/trunk project        A  project/foo.c        A  project/bar.c       

39、; A  project/Makefile        .        Checked out revision 1.    现在，我们在一个新的 project 目录下就有了仓库中一部分数据的一个私人副本了。你可以在本地工作副本上编辑某个文件，然后再将那些修改提交到仓库中。        ?进入工作副本目录，修改文件内容； 

40、0;      ?运行 svn diff 来检查你对文件的修改情况；        ?运行 svn commit 来将新版本的文件提交到仓库中；        ?运行 svn update 来使用仓库中最新的版本来更新你的本地工作副本。    如果想知道我们可以对"本地工作副本"所作的事情，请参阅第三章使用指南。    这时，你

41、可以选择是否让其他人通过网络访问你的仓库。你可以阅读第六章服务器配置来学习不同的服务器程序和如何配置它们第二章 基本概念    本章是对 Subversion 的一个简短的介绍。如果你是使用版本控制工具的新手，这一章将非常适合你。我们先从版本控制的一般概念说起，接着会谈到 Subversion 底层的具体思想以及一些简单的案例。    尽管在本章的案例中我们展示的是如何协同管理软件源代码，但请记住，Subversion 可以管理任何类型的文件集合，而并不仅限于源程序。第二章 基本概念    本章是对 Su

42、bversion 的一个简短的介绍。如果你是使用版本控制工具的新手，这一章将非常适合你。我们先从版本控制的一般概念说起，接着会谈到 Subversion 底层的具体思想以及一些简单的案例。    尽管在本章的案例中我们展示的是如何协同管理软件源代码，但请记住，Subversion 可以管理任何类型的文件集合，而并不仅限于源程序。2.1 仓库（The Repository）    Subversion 是一个集中式的系统。它的核心是一个用来存放数据的中心仓库。中心仓库使用典型的文件和目录层次结构树状结构来存储信息。许许多多的客户端可以连

43、接到 中心仓库，然后读取或者写入文件。客户端通过写文件来使其他人共享，也可以读取其它客户端所写入的文件。下面的图2.1描述了这样的一个典型的客户端/服 务器系统模型。               图2.1    有趣的是，到此为止，这个仓库听起来像是一个典型的文件服务器。而且确实，仓库就是一种文件服务器，只是不是通常的那种。Subversion 仓库可以记录写入仓库的每一次更改。这些更改包括对每一个文件的每一次修改，甚至是对目

44、录本身的修改，例如添加文件、删除文件和对文件和目录的重新编排。 这些特性使得 Subversion 仓库与一般的文件服务器相比较为特殊。    当一个客户端读取仓库中的数据时，他通常只能看到最新版本的文件目录。但是客户端同样可以读取文件和目录以前某个时刻的状态。例如，客户端可以这样做查 询："上个星期三这个目录包含什么文件？"或者是"修改这个文件的最后一个人是谁？他做了什么修改？"。这类问题正是版本控制系统的核心：记录和跟踪数据 的修改历史。2.2 版本控制模型    版本控制系统的核心任务是使

45、得数据可以协作处理和共享。但是不同的系统使用不同的策略来达到这个目标。 文件共享的问题    所有的版本控制系统都必须解决一个共同的基本问题：如何让用户来共享信息，并且还要避免他们不小心覆盖掉别人对仓库中数据作过的修改？毕竟，这种情况太容易发生了。    让我们先来看看下面的图2.2 "要避免的问题"。假设我们有两个合作开发者：Harry 和 Sally。他们两个人在同一个时间决定对仓库中的同一个文件进行编辑。如果 Harry 先将他的修改保存到仓库中，那么可能在很短时间之后，Sally 会使用她的新版本文件覆盖掉

46、仓库中该文件。由于系统记录了 Harry 对文件的修改，但是这些修改并没有出现在 Sally 的新版本文件中。这样，Harry 的工作实际上就丢掉了，或者说在最新版本的文件中漏掉了。这是我们一定要避免出现的情景。    图2.2 要避免的问题 "锁定修改解锁" 方案    许多版本控制系统都使用"锁定修改解锁"模型来解决这个问题。在这样一个系统中，仓库在一个特定的时刻只允许一个人对某个文件进行修改。首先， Harry 必须在修改文件之前"锁定"它。锁定一个文件很像是从图书馆借

47、出一本书；如果 Harry 锁定了一个文件，那么 Sally 就不能对那个文件作任何修改了。如果 Sally 也试图锁定这个文件，仓库将禁止这项操作。她只能读取该文件，然后等待 Harry 完成他的修改并解锁文件。在 Harry 解锁那个文件之后，他的回合就结束了。这是轮到 Sally 来锁定和编辑文件。图2.3 简单的演示了这种方案。    图2.3 "锁定修改解锁"方案    这种方案的问题是它有一点过于严格了，经常会阻塞用户的使用：    ?锁定可能会带来管理问题。有时 Harr

48、y 锁定了一个文件，但是随后却忘了这回事。同时，Sally 的任务却因为仍然在等待编辑那个文件而停滞不前。现在，Harry 去休假了。Sally 只能是去找管理员来释放 Harry 对这个文件的锁定。这种情况最终导致了项目不必要的延迟和宝贵时间的浪费。    ?锁定可能导致不必要的串行工作。如果 Harry 要编辑一个文本文件的开头部分，而 Sally 只想编辑同一个文件的结尾部分，这些更改根本不会重叠和冲突。假设他们的修改可以很好的合并在一起，他们本可以同时对文件进行修改，而不会引起大的混乱。 这种情况下并没有必要非得一个一个的串行工作。  

49、  ?锁定可能会引起潜在的不安全性。假如，Harry 锁定了文件 A 进行编辑，而同时，Sally 则锁定了文件 B 进行编辑。但是假设文件 A 和 B 是互相依赖的两个文件，两人在两个文件上所作的改动是不兼容的。一下子，A 和 B 同时都不能工作了。锁定机制很难解决这个问题。Harry 和 Sally 很容易在锁定文件后就主观的认为已经获得了一个安全的、隔绝的任务，这样就导致了他们不可能尽早地讨论文件修改的兼容性问题。 "复制修改合并"方案    Subversion、CVS以及其他一些版本控制系统使用"复制修改合并&qu

50、ot;模型来代替锁定。在这种模型中，每一个用户的客户端软件从中央仓库创建出 一份个人的工作副本仓库中文件和目录的本地映射。之后，用户就可以并行工作，修改手中的私有副本。最后，这些私有副本合并成为一个全新的版本。版本控 制系统常常需要合并，但是最终，操作者本身必须负责让合并工作正确进行。    这里有一个例子。Harry 和 Sally 都从仓库中复制出一份同一个项目的工作副本。他们同步工作，并且同时对工作副本中的同一个文件 A 作修改。Sally 先将她的修改保存到仓库中。当 Harry 也准备保存他的修改时，仓库会提示说他的文件是"过时"的。

51、换句话说，在他最后复制文件 A 之后，文件 A 不知何时已经发生了变化。所以，Harry 要求他的客户端将仓库中的新的变化"合并"到他的工作副本中。很有可能，Sally 的修改并没有覆盖掉他所作的工作。这样，一旦他将两部分修改集成到一起，Harry 就可以将他的工作副本保存到仓库中。图2.4 "复制修改合并方案"和图2.5 "复制修改合并方案（续）"描述了这个过程。    图2.4 "复制修改合并方案"    图2.5 "复制修改合并方案（续）&

52、quot;    但是，如果 Sally 的修改会覆盖掉 Harry 的工作怎么办？这种情况叫做"冲突（conflict）"，却也称不上是什么问题。当 Harry 要求他的客户端软件合并仓库中的最新修改到工作副本时，文件 A 被标记为冲突状态。这时，他可以看到相互冲突的两份修改，并且手动选择如何处理。注意，软件并不能自动解决冲突。只有人本身才有能力理解和做出合理的选 择。一旦 Harry 手动解决了那些可能导致覆盖的修改（也许这个过程中需要和 Sally 协商一下），他就可以安全地将合并后的文件保存到仓库中了。   

53、; 复制修改合并模型也许听起来有一点混乱，但是实际上，它工作地非常的稳定。用户可以并行工作，完全不需要等待其他人。当他们在同一个文件上工作时，其实大多数的并行修改都不会覆盖对方，冲突不会常常发生。用于解决冲突的时间远远少于锁定系统所带来的时间浪费。    最终，我们将所有的问题归结为一个关键因素：用户交流。如果用户很少交流，不论是语法的还是语义的冲突都会增加。没有哪个系统可以让用户完美地交流，也没 有哪个系统可以自动检查出语义上的冲突。所以，不要被那种锁定系统可以解决冲突的虚假承诺所麻痹，事实上，锁定系统除了限制生产力之外一无是处。2.3 实际中的 Subvers

54、ion    现在是让我们从抽象概念过渡到具体实践的时候了。在这一节中，我们会演示一个真实的例子。    工作副本    在上文中，我们已经知道了工作副本这个概念了。在这里，我们来演示一下如何使用 Subversion 的客户端来创建和使用工作副本。    一个 Subversion 的工作副本其实就是本地系统中的一个普通的文件目录树。你可以使用任何方式来编辑这些文件。如果是源代码文件的话，你也可以像通常情况那样去编译它们。工 作副本是你的私人工作区。如果你不明确的要求，Su

55、bversion 绝不会合并其他人的修改，也不会让其他人看到你做的修改。    在你已经修改完工作副本中的文件，并且确信修改正确后，就可以将这些修改公开给同一个项目中的其他工作人员。Subversion 提供了将文件写入仓库的命令。通过这种方式来达到公布你的修改的目的。如果其他人公布了他们的修改，也可以使用 Subversion 提供的命令来合并修改（通过从仓库中读出文件）。    工作副本中也包含一些额外的文件。它们是由 Subversion 创建和维护的，用来辅助完成这些命令。最典型的情况是，每一个目录都包含一个叫做 .svn 的

56、子目录。该目录也被称为"工作副本管理目录"。在管理目录中的那些文件可以帮助 Subversion 来识别哪些文件包含没有发布的修改，以及哪些文件已经过期了。    通常，一个 Subversion 的仓库会包含几个项目，而每一个项目都是仓库的目录的一个子目录。这样，用户的工作副本也就对应于仓库中一个特定的子目录。    例如，假设我们有一个包含两个软件项目的仓库。它们分别叫做 paint 和 calc。每一个项目都在它们自己的顶层子目录下。如图2.6 "仓库的文件系统"所示。 

57、0;  图2.6 "仓库的文件系统"    为了获得一份工作副本，我们必须先"check out"仓库中的某一个子目录。（check out 这个词听起来有点像是要锁定什么资源，但事实上不是，它只是简单的创建一份工作副本而已）。例如，我们来 check out 一个 /calc 项目的工作副本：    $ svn checkout     A  calc    A  calc/Makefile &

58、#160;  A  calc/integer.c    A  calc/button.c    $ ls -A calc    Makefile  integer.c  button.c  .svn/    上面以字母 A 开头的行表明了 Subversion 已经为我们的工作副本添加了一些东西。现在，我们拥有了仓库中 /calc 目录的一份私有副本。另外还有一个额外的目录 .svn 用来保存 Subversion

59、需要使用的额外信息。我们前面已经提到过它了。    （开始）    Repository URLs    Subversion 的仓库可以通过多种方式来访问，例如本地磁盘或者是网络协议。然而，一个仓库的位置总是以 URL 的方式出现。表2-1描述了不同的访问方法所对应的 URL 样式。    表2-1 仓库存取 URLs        样式      

60、60;          存取方式     file:/              直接从本地磁盘上访问仓库     http:/              

61、通过 WebDAV 协议访问 Apache 服务器，进而访问仓库     https:/              和 http:/ 相同，但使用 SSL 来作加密     svn:/                通过自定义的协议访问一个

62、 svnserve 服务器     svn+ssh:/            和 svn:/ 相同，但通过一个 SSH 通道来使用    很多情况下，Subversion 的 URLs 都使用标准的语法，并允许在 URL 中使用服务器名称和端口号。记住， file:/ 方式只在本地服务器上有效。也就是说客户端和服务器在同一台机器上的情况。事实上，按照惯例，在 URL 中的服务器名称必须是空的或者是 localhost

63、：    $ svn checkout file:/path/to/repos    .    $ svn checkout file:/localhost/path/to/repos    .    同样，在 Windows 平台上使用 file:/ 方式时，也需要使用一种非官方的"标准语法"来存取本地的仓库。除非是仓库和客户端不在同一个驱动器上。下面两种 URL 语法都可以正确工作。假设 X 是仓库所在的驱动器。 

64、;   C:> svn checkout file:/X:/path/to/repos    .    C:> svn checkout "file:/X|/path/to/repos"    .    在第二种语法中，你必须使用引号来标记一下，以防止 '|' 被当作管道命令。    注意：这里的 URL 使用斜杠 '/' 而不是反斜杠 '' 。&

65、#160;   （结束）    假设你对 button.c 文件作了修改。由于 .svn 目录中记录了文件的修改日期和原始内容，Subversion 可以指出你已经修改了文件。但是，如果你不明确声明，Subversion 不会自作主张去把这些修改发布。发布修改的动作通常叫做"提交"（committing or checking in）修改到仓库。    你可以使用 Subversion 的 commit 命令来发布修改：    $ svn commit button

66、.c    Sending        button.c    Transmitting file data .    Committed revision 57.    这样，你对 button.c 文件的修改就提交到仓库了；如果其他用户 check out 了一份 /calc 的工作副本，他们就会在最新版本的文件里看到你做的修改了。    假如你有一个协作开发者 Sall

67、y 。她和你同时 check out 了 /calc 目录的工作副本。当你提交你对 button.c 的修改后，Sally 的工作副本就变成了旧的了；Subversion 只有在用户请求时才会更新本地工作副本。    如果 Sally 想让她的项目保持更新，她可以使用 update 命令来请求 Subversion 更新她的本地工作副本。这样，你的修改将会合并到她的工作副本，当然还有在她签出（check out）期间其他人所作的修改。    $ pwd    /home/sally/calc &

68、#160;  $ ls -A    .svn/    Makefile    integer.c    button.c    $ svn update    U button.c    执行 svn update 时候的输出内容表明 Subversion 更新了 button.c 的内容。Sally 并不需要指定更新哪个文件；Subversion 根据 .svn 目录以及仓库

69、中的信息来决定哪些文件将被更新。 修订本    一个 svn commit 操作可以将任意数量的文件和目录的修改发布作为一个单独的原子事务来处理。在你的工作副本中，你可以修改文件内容，创建、删除、重命名以及复制文件和目录，然后作为一个单独的单元来提交所有这些修改。    在仓库中，每一次提交都被作为一个原子事务来对待：要么所有的提交都成功执行，要么什么都不发生。Subversion 试图在面对程序崩溃、系统崩溃、网络问题和其他用户的动作时保留这种原子性。    每当仓库接受一次提交，仓库中的文件系统目录都

70、会创建一种新的状态，叫做一个修订本。每一个修订本都被赋予一个唯一的自然数，并且每一个修订本的数字都比前一个要大。刚刚建立的仓库的初始的版本是 0 ，只包含一个空的根目录。    图2.7 "仓库"是一个仓库的想象图。设想一个修订版编号的数列，从 0 开始，从左延伸到右。每一个修订版编号都对应一个画下面的目录树，而每一个目录树就是在每一次提交之后的仓库的"快照"。    图2.7    （表格开始）    全局修订本编号： &#

71、160;  Subversion 的修订版编号是针对整个目录树的，而不是某一个独立的文件。这与其他许多的版本控制系统不同。每一个修订版编号都代表了仓库中一个树在某次提交后的一个特 定状态。从另一个角度来讲，修订版 N 表示经过了 N 提交之后的仓库目录树。如果某人说"文件 foo.c 的 revision 5"，那么应该理解为"在项目的 revision 5 中看到的 foo.c 文件"。值得注意的事，通常 revisions N 和 revisions M 的某个文件并不一定非得是不同的。由于 CVS 使用每一个文件一个修订版编号的方式，CV

72、S 的用户请阅读附录A Subversion for CVS Users。    （表格结束）    有一点非常重要，工作副本并不总是对应于仓库中一个单一的修订版，有时可能会包含几个其他修订版的文件。举个例子来说，假设你 check out 了一个仓库中的项目，修订版编号是 4 ：    calc/Makefile:  4        integer.c:  4    

73、60;   button.c:  4    此时，这份工作副本之对应于修订版4。然而，如果你对 button.c 做了修改，并且提交了修改。如果没有其他人提交其他修改的话，你的这个动作会创建仓库中项目的另一个修订版编号：5，而你的工作副本将会是这样：    calc/Makefile:  4        integer.c:  4       

74、button.c:  5    假设这个时候，Sally 提交了她对 integer.c 的修改，创建了修订版 6。如果你使用 svn update 命令来更新工作副本，则会看到：    calc/Makefile:  6        integer.c:  6        button.c:  6    Sally 的修改

75、会出现在你的本地工作副本中，而你的修改也仍然在 button.c 中。在这个例子里，文本文件 Makefile 在修订版4、5、6中是一样的，但是 Subversion 还是会把 Makefile 的本地工作副本标示为 revision 6 来表示它是最新的。所以，当你对你的工作副本做过一次更新之后，它将只对应仓库中"一个"修订版。 工作副本如何跟踪仓库    对于工作副本中的每一文件，Subversion 在 .svn/ 管理区中保存两条必需的信息：    ?这个工作文件的修订版编号（也叫做文件的"工作

76、版本"）；    ?本地副本最后一次更新的时间戳。    基于这些信息，Subversion 通过和仓库来通讯，可以报告一个工作文件处于下面四种状态中的哪一种：        未改变的，并且是最新的            文件没有在工作副本中修改过，而且也没有人向仓库提交过修改。对此文件执行 svn commit 或是 svn update 是无效的。        在本地修改过，是最新的            文件在工作副本中修改过，没有其他人提交过目前修订版的修改。这时，可以执行 svn commit 来提交修改。而执行 svn update 是无效的。        未改变的，但是过时的