TortoiseSVN操作使用

说明
SVN常用于程序代码版本控制,由于业务需求需将生产资料通过SVN进行管控,涉及人员众多,权限分支管理需要细化,特此记录SVN的学习操作.

前言

• 版本控制是管理信息修改的艺术，它一直是程序员最重要的工具，程序员经常会花时间作出小的修改，
  然后又在某一天取消了这些修改，想象一下一个开发者并行工作的团队或许是同时工作在同一个文
  件！你就会明白为什么一个好的系统需要管理潜在的混乱。

1.什么是SVN

• TortoiseSVN 是一个 Windows 下的版本控制系统 Apache™ Subversion® 的客户端工具。就是
  说，TortoiseSVN 常年管理文件和目录。文件存储于一个中央版本库中。版本库就像一个常见的文件服
  务器，除了它保存你对文件和目录所有的改变。这一特性使得你可以恢复文件的旧版本并查看历史-谁
  在什么时间如何进行的修改。这就是为什么很多人认为 Subversion 和版本控制系统是一种“时间机
  器”。
  某些版本控制系统也是软件配置管理(SCM)系统，这种系统经过精巧的设计，专门用来管理源代码树，
  并且具备许多与软件开发有关的特性
  比如，对编程语言的支持，或者提供程序构建工具。不过
  Subversion 并不是这样的系统；它是一个通用系统，可以管理任何类型的文件集，包括源代码。

2.SVN的特性

• 外壳集成
  TortoiseSVN 无缝地整合进 Windows 的外壳(例如资源管理器)。这意味着你可以继续使用已经熟悉
  的工具。而且当需要版本控制功能时你不用切换到不同的应用程序。
  而且你并没有被限制在 Windows 资源管理器中; TortoiseSVN 的右键菜单可以在很多其它文件管理器中以及标准 Windows 程序的 文件/打开 对话框中被调出。
  不过，你应该记住 TortoiseSVN 是专门作为 Windows 资源管理器的扩展进行开发的。因此，有可能在其它程序中整合的不那么完整，例如重载图标可能不显示

• 重载图标
  每个版本控制的文件和目录的状态使用小的重载图标表示，可以让你立刻看出工作副本的状态。

• 图形用户界面
  当你列出文件或文件夹的更改时，你可以点击任意版本查看提交注释。也可以看到更改过的文件列表 --> 只要双击文件就可以查看更改内容。
  提交对话框列出了本次提交将要包括的条目，每一个条目有一个复选框，所以你可以选择包括哪些条目。未版本控制的文件也会被列出，以防你忘记添加新文件。

• Subversion 命令的简便访问
  所有的 Subversion 命令存在于资源管理器的右键菜单,TortoiseSVN 在那里添加子菜单。

• 目录版本控制
  CVS 只能追踪单个文件的历史，但是 Subversion 实现了一个“虚拟”文件系统，可以追踪整个目录树的修改，文件和目录都是版本控制的，结果就是可以在客户端对文件和目录执行移动和复制命令。

• 原子提交

• 提交要么完全进入版本库，要么一点都没有，这允许开发者以一个逻辑块提交修改。

• 版本控制的元数据
  每个文件和目录都有一组附加的“属性”，你可以发明和保存任意的键/值对，属性是版本控制的，就像文件内容。

• 可选的网络层
  Subversion 在版本库访问方面有一个抽象概念，利于人们去实现新的网络机制，Subversion的“高级”服务器是 Apache 网络服务器的一个模块，使用 HTTP 的变种协议 WebDAV/DeltaV 通讯，这给了 Subversion 在稳定性和交互性方面很大的好处，可以直接使用服务器的特性，例如认证、授权、传输压缩和版本库浏览等等。也有一个轻型的，单独运行的 Subversion 服务器，这个服务器使用自己的协议，可以轻松的用 SSH 封装。

• 一致的数据处理
  Subversion 使用二进制文件差异算法表达文件的差异，对文本文件（人类可读）和二进制文件（人类不可读）进行相同的处理方式，两种类型的文件都压缩存放在版本库中，之后差异结果在网络上双向传递。

• 高效的分支和标签
  分支与标签的成本不需要与工程的大小成比例增长，Subversion 建立分支与标签时只是单纯的使用一种类似于硬链接的机制复制项目。因而这类操作通常只会花费很少并且相对固定的时间，以及
  占用很小的版本库空间。

3.许可协议

• TortoiseSVN 是一个基于 GNU 通用公共许可协议 (GPL) 开发的开源软件。它可以免费下载和使用，无论是个人或是商业目的，并且没有安装数量的限制。

4.SVN发展

4.1 SVN历史

• 2002年，Tim Kemp 发现 Subversion 是一个非常好的版本管理系统，但是缺乏一个好的图形界面客户端程序。做一个与 Windows 外壳整合的 Subversion 客户端程序的想法是受一个叫 TortoiseCVS 的 CVS客户端程序所启发的。Tim 研究了 TortoiseCVS 的源码并以此为 TortoiseSVN 的基础。他开始运作这个项目，注册了域名 tortoisesvn.org 并且将源码放在了网上。
  就在同时， Stefan Küng 正在寻找一个好用的并且免费的版本控制系统。他找到了 Subversion 和TortoiseSVN 的源码。因为 TortoiseSVN 还不能使用，他加入了项目并开始编码。很快，他就重写了现有的大部分代码并开始添加命令和功能，到了某个时段，最初的代码已经都被改写了。
  由于 Subversion 变得越来越稳定，它吸引了越来越多用户，他们同时也开始使用 TortoiseSVN 作为Subversion 的客户端程序。用户数量快速增长(并且每天还在增长)。这时候，Lübbe Onken 提出帮助项目提供精美的图标和 TortoiseSVN 的标志。现在他负责照看网站和管理多语言翻译。
  随着时间推移，其他的版本控制系统都有着自己的 Tortoise 客户端，这导致了在资源管理器中图标重载的问题：这些图标重载有着数量的限制，仅一个 Tortoise 客户端也能轻易超过那个限制。因而
  Stefan Küng 使用了 Tortoise 图标重载组件使得所有 Tortoise 客户端可以使用相同的图标重载。现在所有的开源 Tortoise 客户端甚至一些非 Tortoise 客户端也能使用分享的组件。

4.2 致谢

• Tim Kemp
  启动 TortoiseSVN 项目
• Stefan Küng
  辛苦工作使 TortoiseSVN 达到现在的样子，并领导整个项目。
• Lübbe Onken
  制作了漂亮的图标，标志，跟踪错误，翻译并且维护翻译结果
• Simon Large
  维护文档
• Stefan Fuhrmann
  日志缓存和版本图
• Subversion 手册
  为了对 Subversion 大量介绍，我们复制了其第二章
• Tigris 样式项目
  我们在本文重用了一些样式
• 我们的贡献者
  提供了补丁、错误汇报及新的想法，并且在邮件列表上回答了其他人的问题
• 我们的捐赠者
  他们发送给我们的那些音乐带来了快乐

5.阅读指南

本手册是为那些想使用 Subversion 来管理数据，并且喜欢使用图形界面客户端程序替代命令行程序的电脑用户编写的。TortoiseSVN 是 Windows 外壳扩展，并且假设用户熟悉和使用 Windows 资源管理器。

• 在 前言 一章里解释了什么是 TortoiseSVN，一些关于TortoiseSVN 项目和开发人员社区的消息，以及使用和分发它的许可条件。
• 在 第 1 章 开始 一章里解释了如何在电脑中安装 TortoiseSVN，以及如何立刻开始使用。
• 在第 2 章 基本版本控制概念一章里简短地介绍了 Subversion 版本控制系统，Subversion
  是 TortoiseSVN 的基础。这一章借用了 Subversion 项目的文档，介绍了各种版本控制模式，以及Subversion 的工作原理。
• 第 3 章 版本库 这一章介绍了如何设置一个本地版本库，这对于在一台单独的个人计算机上测试
  Subversion 和 TortoiseSVN 来说是相当有用的。这一章节也介绍了一些版本库管理的内容，这与管理服务器上的版本库是有一定联系的。
• 第 4 章 日常使用指南是最重要的章节，介绍了 TortoiseSVN 最主要特性的使用。它以教程的形式，从检出一个工作副本开始，然后修改，提交你的修改，之后进入高级主题。
• 第 5 章 项目监视器解释了如何监视您的Subversion项目，这样您就不会错过其他团队成员的重要提交。
• 第 6 章 SubWCRev 程序 是 TortoiseSVN 的一个独立程序，可以从工作副本抽取信息并记录到一个文件，可以用来在项目中包含构建信息。
• 附录 B, 如何实现 …这一节回答了一些操作方面的常见问题。这些常见问题在其他章节没有被明确的提到过。
• 附录 D, TortoiseSVN 操作 这一节展示了如何使用命令行调用TortoiseSVN 的 GUI 对话框，当你在使用脚本时仍希望用户交互时非常有用。
• 附录 E, 命令行交叉索引给出了 TortoiseSVN 命令与其对应的 Subversion 命令行工具 svn.exe 命令之间的关系。

术语

• 为了使文档更加易读，所有 TortoiseSVN 的窗口名和菜单名使用不同的字体，例如日志对话框。

• 菜单选择使用箭头显示。TortoiseSVN → 显示日志的含义是: 从 TortoiseSVN 右键菜单选择显示日志。

• 在 TortoiseSVN 对话框中出现的右键菜单，可能是这个样子: 右键菜单 → 另存为 …

• 用户界面按钮的显示形式: 点击OK以继续。

• 用户动作使用粗体字表示。Alt+A: 表示按住键盘上的 Alt 键同时按下 A 键。右键拖拽: 表示按住鼠标右键同时拖拽条目到新位置。

• 系统输出和键盘输入也使用不同的字体显示。
  

使用图标标记的重要提示。

技巧让你的生活更加简单。

操作时需要小心的地方。

需要非常小心操作的地方。如果忽略警告内容将会导致数据损坏或其它严重后果。

一、开始

这一节面向那些想要了解 TortoiseSVN 的用途并且想试用一下它的人。介绍了如何安装 TortoiseSVN及设置本地版本库，还将展示最常用的操作。

1.1 安装 TortoiseSVN

1.1.1 系统要求

• TortoiseSVN 能够运行在 Windows Vista 或更高版本，并且提供32位与64位系统的支持。适用与64位Windows 系统的安装程序同时包含32位的拓展部件。这意味着您无需单独安装32位版本的 TortoiseSVN就可以在32位的应用程序中使用右键菜单和图标重载。

• 自 1.2.0 版起放弃对 Windows 98， Windows ME 和 Windows NT 4 的支持。自 1.7.0 版起放弃对Windows 2000 和 XP SP2 的支持。自 1.9.0 版起放弃对Windows XP SP3的支持。如果需要，仍然可
  以下载、安装旧版本。

1.1.2 安装

TortoiseSVN 以简单易用的安装包的形式发布。双击安装文件并按照提示操作。安装文件会照顾其余的
事情。安装结束后不要忘记重启电脑。

你需要管理员权限来安装 TortoiseSVN。必要的话安装程序会向您要求管理员证书。

TortoiseSVN 提供语言补丁(Language pack)，它可以将用户界面翻译成多种文字。请查看 附录 G, 语言包和拼写检查器 获得更多关于安装语言补丁的信息。

如果在安装TortoiseSVN期间或之后遇到任何问题，请参阅在线常见问题解答： SVN技术支持

1.2 基本概念

在我们开始实地操作之前，非常有必要对 Subversion 是如何工作的以及用到的术语做一个大致了解。

• 版本库
  Subversion 使用集中的数据库，它包含了所有的版本控制文件及其完整历史。这个数据库就是版本库。版本库通常位于运行 Subversion 服务器的文件服务器上，向 Subversion 客户端(例如
  TortoiseSVN)提供需要的数据。如果只备份一个东西，请备份版本库，因为它是你数据的主副本。
• 工作副本
  这是实际工作的地方。每一个开发者在自己的电脑上都有属于自己的工作副本，有时可以将其理解为沙箱。你可以将最新的版本从版本库上取下来，在本地的副本上工作而不影响其他人，如果对更改满意就可以将其提交到版本库中。
  Subversion 工作副本不包含项目的历史， 但是它保存了你修改前的本件的副本，就像这些文件在版本库中的状态一样。这意味着你可以轻而易举的准确检查出都做了哪些改动。

你还要知道从哪里开始运行 TortoiseSVN，因为在开始菜单中看不到。这是因为 TortoiseSVN 是一个外壳扩展，
所以第一步，打开 Windows 资源管理器。在资源管理器中用右键单击一个文件夹，然后就会发现在右键菜单中出现一些新的条目，就像这样:

图 1.1. 未版本控制文件夹的 TortoiseSVN 菜单

1.3 开始试用

这一节通过一个小的实验版本库向你展示如何开始一些最普通的用途。实际上这里没有介绍全部功能 -这只是一个快速开始向导而已。
一旦你开始使用，你应该花点时间读一下本手册的其它部分，在那里将会详细地介绍本软件的方方面面。也会介绍更多关于设置一个全功能 Subversion 服务器的内容。

1.3.1 创建版本库

对于一个实际的项目，需要在一个安全的地方创建版本库并设置 Subversion 服务器来控制它。而对于本教程而言，我们将会使用 Subversion 的本机版本库功能，该特性使得用户可以直接访问本机硬盘上的版本库而不需要服务器。

首先在您的个人计算机上建立一个新的空目录。这个目录可以建立在任何位置，不过在这一教程中，我们将建立 C:\svn_repos 。现在，你可以右键点击这个新文件夹，从右键菜单中选择TortoiseSVN → 在这里创建版本库… 。
这样做之后，一个可以供您所用的版本库就在这个文件夹中创建好了。我们还可以通过点击 创建目录结构 来创建标准目录结构。

对于测试和评估用途来说，本机版本库功能非常有用，但除非你是一个只使用自己电脑进行独自工作的开发者，否则你应该使用全功能的 Subversion 服务器。有些小公司为了避免设置服务器的工作，就通过网络共享来存取版本库。不要这样做。这样会丢失数据。阅读第 3.1.4 节 “访问网络共享磁盘上的版本库” 了解为什么这是一个坏主意，以及如何设置服务器。

1.3.2 导入项目

我们有一个版本库，但它现在完全是空的。假设我想要添加一些文件到C:\Projects\Widget1，在文件资源管理器中导航到Widget1并单击右键，选择 TortoiseSVN → 导入…弹出导入对话框

图 1.2. 导入对话框

输入版本库URL，可以是互联网上任何特定的版本库。既然这样，我们也可以指向本地版本库，如file:///c:/svn_repos/trunk,并添加项目名称Widget1。请注意，file: 协议后面始终有三个斜杠。

• 这个对话框中另一个重要的功能就是导入信息文本框，你可以输入一段信息来描述你的操作。当你查看项目的历史时，这些提交信息是记录了你修改什么和为什么修改的宝贵资料。在这个例子中，我们可以简单的写一下，例如“导入 Widget1 项目”。点击确定，文件夹就加入到版本库中了。

1.3.3 检出工作副本

现在，你创建好了你的版本库，这时，还需要创建一个工作副本用于你平时编写代码。注意，当你把一个文件夹导入到版本库这个过程并不能使刚才的文件夹变成一个工作副本。

在默认设置时，检出菜单项不在TortoiseSVN 子目录而在资源管理器根目录。不在子目录中的 TortoiseSVN 命令有SVN前缀：SVN 检出…

你会注意到，这个文件夹看起来与我们原来的文件夹不一样。每一个文件的左下角都有一个绿色的对钩。它们就是只出现在工作副本中的 TortoiseSVN 状态图标。绿色的图标表示文件未被修改，和版本库中的文件版本一致。

1.3.4 进行修改

在 Widget1-Dev 文件夹中，我们开始编辑文件 - 假设我们对 Widget1.c 和 ReadMe.txt 做出了一些修改。注意这些文件的图标上的小图标变成了红色，这说明本地文件已经被修改了。

但是我们做了哪些更改？右键单击任意一个修改过的文件然后选择 TortoiseSVN → 比较差异。启动TortoiseSVN 的文件比较工具，准确地显示哪些行被修改了。

图 1.3. 文件差异查看器

OK,我们对这些更改很满意，让我们更新版本库。这个动作叫 提交 更改。右键单击文件夹 Widget1-Dev 然后选择 TortoiseSVN → 提交。提交对话框列出了修改过的文件，每一个都有一个复选框。你可以选中列表中的部分文件，但在这个例子中我们将要提交全部修改过文件。输入一段信息来描述做了什么修改然后单击 确定。进度对话框显示被上传到版本库中的文件并且完成提交。

1.3.5 添加更多的文件

随着项目的发展，需要添加新文件 - 例如说你要添加新功能，有了新文件 Extras.c 还要在现有的文件 Makefile 中加入起对该文件的引用。

• 右键单击文件夹然后选择 TortoiseSVN → 增 加。 加入对话框显示了所有未被版本控制的文件，你可以选择哪些文件要被添加。
• 另一个增加文件的方法是右键单击文件自身然后选择 TortoiseSVN → 加入。
  现在当你提交文件夹时，新文件会显示为增加，原有的文件显示为修改。注意你可以双击修改的文件查看做了哪些改动。

1.3.6 查看项目历史

日志对话框是TortoiseSVN 最有用的功能之一。它把你所有的文件/文件夹提交记录显示为一个列表，并且显示你输入的详细提交信息（你按照建议输入提交信息了吗？如果没有，现在知道多重要了吧）。

图 1.4. 日志对话框

好吧，我在这儿偷个懒，用一张TortoiseSVN 版本库的截图。
对话框的上部显示提交的版本列表以及提交信息的开头。如果选中版本列表中的任意一个，对话框的中部显示该版本完整的日志消息，对话框的底部显示更改的文件和文件夹列表。
对话框的每一部分都有右键菜单提供很多使用这些信息的方法。在底部可以 双击 文件来完整的查看该版本所做的修改。参阅 第 4.10 节 “版本日志对话框” 获得完整的内容。

1.3.7 撤销更改

所有的版本控制系统都有的功能就是让你可以撤销之前做的更改。如你预料的一样，TortoiseSVN 非常容易做到这一点。
如果你想抛弃还没有提交的更改并将文件复原到修改之前的状态，TortoiseSVN → SVN 还原 就是你的好伙伴。它抛弃了所做的更改(扔到回收站里)并复原到修改之前的版本。如果你想抛弃更改的一部分，可以使用 TortoiseMerge 来查看区别并有选择的复原被修改的文件行。
如果你要撤销某一个特定版本的影响，启动日志对话框，找到不想要的版本。选择 右键菜单 → 复原此版本作出的修改 然后这些更改就会被撤销。

1.4 继续前进…

这个向导提供一个非常短小的例子来展示 TortoiseSVN 的最重要和最有用的功能，当然，这里很有很多内容没有被覆盖。我们强烈推荐你花点时间阅读这本手册剩余的部分，尤其是 第 4 章 日常使用指南，这一章展示了很多日常工作的详细内容。
我们已经不辞劳苦的确保本手册有丰富的信息并容易阅读，但我们也承认在使用过程中还有很多的困难! 花点时间，独自用测试版本库练练手。最好的方法就是在实践中学习。

二、基本版本控制概念

本章修改自《使用 Subversion 进行版本管理》的相同章节，它的在线版本位于: 开源版本控制的标准。
这一章是对 Subversion 一个简短随意的介绍，如果你对版本控制很陌生，这一章节完全是为你准备的，我们从讨论基本概念开始，深入理解 Subversion 的思想，然后展示许多简单的实例。
尽管我们的例子展示了人们如何分享程序源代码，仍然要记住 Subversion 可以控制所有类型的文件－它并没有限制只为程序员工作。

2.1 版本库

Subversion 是一种集中的分享信息的系统，它的核心是版本库，储存所有的数据，版本库按照文件树形式储存数据－包括文件和目录，任意数量的客户端可以连接到版本库，读写这些文件。通过写数据，别人可以看到这些信息；通过读数据，可以看到别人的修改。

图 2.1. 一个典型的客户/服务器系统

所以为什么这很有趣呢？讲了这么多，让人感觉这是一种普通的文件服务器，但实际上，版本库是另一种文件服务器，而不是你常见的那一种。最特别的是 Subversion 会记录每一次的更改，不仅针对文件也包括目录本身，包括增加、删除和重新组织文件和目录。
通常情况下，客户端只会从版本库中读取最新版本的文件树，但客户端还拥有读取前一版本文件树的功能。例如，客户端可以发起这样的请求：“版本库在周三时包含哪些内容？”或者“针对某个文件，最后更改者是谁？具体的改动为何？”这几类问题就是每个版本控制系统最需关注的核心问题：系统需要实时记录与追踪数据变动。

2.2 版本模型

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

2.2.1 文件共享的问题

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

图 2.2. 需要避免的问题

2.2.2 锁定-修改-解锁 方案

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

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

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

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

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

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

2.2.3 复制-修改-合并 方案

Subversion、CVS和其他的一些版本控制系统使用 复制-修改-解锁 模型作为变相的锁定方式。在这种模型下，每个用户的客户端会读取版本库内容，而后针对文件或者项目创建独属于单个用户的工作副本。用户接下来会平行地工作，修改他们的独属副本。最后，这些独属副本会上传并合并为全新的、最终的版本。版本控制系统会协助处理这项合并工作，但最终版的正确成型仍需人类责。
这儿有一个例子。比如说 Harry 和 Sally 参加同一个项目每人都有各自的工作副本，从同一个版本库复制出来的。他们同时工作，在自己的副本中修改同一个文件 A。Sally 先将她的更改保存到版本库
中。 稍后，当 Harry 尝试提交他的更改时，版本库提示他的文件 A 已经过时。换句话说，自从他上次复制文件后，无论如何版本库中的文件 A 已经被修改了。所以 Harry 要用客户端程序将版本库中文
件 A 的新更改 合并 到他的工作副本中。碰巧的是 Sally 的更改和他的不重合; 所以一旦他整合了两人的更改，他就可以把他的工作副本复制回版本库。

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

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

但是如果 Sally 和 Harry 的修改重叠了该怎么办？这种情况叫做冲突，这通常不是个大问题，当Harry 告诉他的客户端去合并版本库的最新修改到自己的工作副本时，他的文件 A 就会处于冲突状
态: 他可以看到一对冲突的修改集，并手工的选择保留一组修改。需要注意的是软件不能自动的解决冲突，只有人可以理解并作出智能的选择，一旦 Harry 手工的解决了冲突(也许需要与 Sally 讨论)，他就可以安全的把合并的文件保存到版本库。
复制-修改-合并模型感觉是有一点混乱，但在实践中，通常运行的很平稳，用户可以并行的工作，不必等待别人，当工作在同一个文件上时，也很少会有重叠发生，冲突并不频繁，处理冲突的时间远比等待解锁花费的时间少。
最后，一切都要归结到一条重要的因素: 用户交流。
当用户交流贫乏，语法和语义的冲突就会增加，没有系统可以强制用户完美的交流，没有系统可以检测语义上的冲突，所以没有任何证据能够承诺锁定系统可以防止冲突，实践中，锁定除了约束了生产力，并没有做什么事。
有一种情况下锁定-修改-解锁模型会更好，也就是你有不可合并的文件，例如你的版本库包含了图片，两个人同时编辑这个文件，没有办法将这两个修改合并，Harry 或 Sally 会丢失他们的修改。

2.2.4 Subversion 怎么做？

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

2.3 Subversion 实战

2.3.1 工作副本

你已经阅读过了关于工作副本的内容，现在我们要讲一讲客户端怎样建立和使用它。

一个 Subversion 工作副本是你本地机器一个普通的目录，保存着一些文件，你可以任意的编辑文件，而且如果是源代码文件，你可以像平常一样编译，你的工作副本是你的私有工作区，在你明确的做了特定操作之前，Subversion 不会把你的修改与其他人的合并，也不会把你的修改展示给别人。
当对工作副本中的文件做了一些更改并确认他们能够正常工作后，Subversion 提供将这些更改公布给同项目的其他人员的命令(通过写入版本库)。如果其他人公布他们的更改，Subversion 提供将这些更
改合并到工作副本的命令(通过读取本版本库)。
Subversion还会在工作副本中创建并管理一些额外的文件，这些文件将用于协助执行命令。特别地，你的工作副本中会包含一个名为.svn的子目录，即该工作副本的管理目录。管理目录中的文件帮助Subversion识别哪些文件包含未发布的更改，哪些文件由于他人的更改已过期。早于1.7版本的Subversion会在工作副本中每一级目录下包含名为.svn的管理子目录。1.7版本开始， Subversion 启
用了全新的策略：每个工作副本只有一个管理子目录，该目录是工作副本根目录的直接子级。
一个典型的 Subversion 的版本库经常包含许多项目的文件(或者说源代码)，通常每一个项目都是版本库的子目录，在这种安排下，一个用户的工作副本往往对应版本库的的一个子目录。
举一个例子，你的版本库包含两个软件项目。

图 2.6. 版本库的文件系统

换句话说，版本库的根目录包含两个子目录: paint 和 calc。要获得工作副本，必须通过 检出 版本库中的某个子树。(术语 检出 听起来好像会锁定和保留资源，但实际上不是这样; 它只是给项目创建了一个私有的副本。)
假设你对button.c做出了修改。由于.svn目录记录了文件的修改日期和原始内容，Subversion得以告知使用者已经更改了这个文件。然而， Subversion 并不会将你的更改展示给全部用户，除非你明确指出要这么做。推送你做出的更改这一举动通常被称作提交修改（或者检入修改）到版本库。
发布你的修改给别人，可以使用 Subversion 的提交命令。
这时你对 button.c 的修改已经提交到了版本库，如果其他人取出了 /calc 的一个工作副本，他们会看到这个文件最新的版本。
假设你有个合作者，Sally，她和你同时取出了 /calc 的一个工作副本，你提交了你对 button.c 的修改，Sally 的工作副本并没有改变，Subversion 只在用户要求的时候才改变工作副本。
要使项目最新，Sally 可以要求 Subversion 更新她的工作副本，通过使用更新命令，可以将你和所有其他人在她上次更新之后的修改合并到她的工作副本。

• 注意，Sally 不必指定要更新的文件，Subversion 利用 .svn 以及版本库的进一步信息决定哪些文件需要更新。

2.3.2 版本库的 URL

Subversion 可以通过多种方式访问－本地磁盘访问，或各种各样不同的网络协议，但一个版本库地址永远都是一个 URL，URL 方案反映了访问方法。

表 2.1. 版本库访问 URL

对于大多数情况，Subversion 的 URL 使用标准格式，允许服务器名称和端口作为 URL 的一部分明确的指出来。
files:// 访问方式一般用于本地访问，尽管它可以使用 UNC 路径来引用网络主机。因此 URL使用这种格式file://hostname/path/to/repos。对于本机而言，URL 中的 hostname 部分必须省略或者使用 localhost。就是因为这个原因，本机路径通常含有 3 个斜线，file:///path/to/repos。
同样，在 Windows 平台上使用 file:// 方案的用户需要使用一种非官方的 “标准” 协议格式来访问那些位于本机其他分区，即与客户端当前所处分区不同的版本库。如下两种格式的 URL 路径是有效的，其中X代表版本库目录所在分区的盘符：

• file:///X:/path/to/repos
  …
• file:///X|/path/to/repos
  …

注意 URL 使用普通的斜杠，而不是 Windows 本地(非 URL)形式的路径。
你可以通过网络共享访问一个FSFS版本库，但由于很多原因不建议你这样做。

• 你会授予所有用户写权限，这样他们就有可能会意外删除或破坏版本库文件系统。
• 不是所有的网络文件共享协议都支持 Subversion 需要的文件锁定，所以你会发现你的版本库被毁了。有一天你会发现你的版本库微妙地崩溃
• 你必须设置正确的访问许可。SAMBA在这方面尤其困难
• 如果有人安装新版客户端升级了版本库格式，那么其他人将无法访问该版本库，直到他们也升级到新版客户端。

2.3.3 修改版本

svn commit 操作可以作为一个原子事务操作发布任意数量文件和目录的修改。在你的工作副本中，你可以改变文件内容，创建、删除、改名和复制文件和目录，然后作为一个整体提交。
在版本库中，每次提交被当作一次原子事务操作: 要么所有的改变发生，要么都不发生，Subversion努力保持原子性以应对程序错误、系统错误、网络问题和其他用户行为。
每当版本库接受了一个提交，文件系统进入了一个新的状态，叫做版本，每个版本被赋予一个独一无二的自然数，一个比一个大，初始修订号是 0，只创建了一个空目录，没有任何内容。
可以形象的把版本库看作一系列树，想象有一组版本号，从 0 开始，从左到右，每一个修订号有一个目录树挂在它下面，每一个树好像是一次提交后的版本库“快照”。

图 2.7. 版本库

• 全局版本号
  不同于其它版本控制系统，Subversion 的版本号是针对整个目录树的，而不是单个文件。每一个版本号代表了一次提交后版本库整个目录树的特定状态，另一种理解是版本 N 代表版本库已经经过了 N 次提交。当 Subversion 用户讨论“foo.c的版本 5”时，他们的实际指得是“在版本 5时的foo.c”。需要注意的是，一个文件的版本 N 和 M 并不表示它必然不同。

需要特别注意的是，工作副本并不一定对应版本库中的单一版本，他们可能包含多个版本的文件。举个例子，你从版本库检出一个工作副本，最新的版本是 4:
calc/Makefile:4
integer.c:4
button.c:4

此刻，工作目录与版本库的版本 4 完全对应，然而，你修改了 button.c 并且提交之后，假设没有别的提交出现，你的提交会在版本库建立版本 5，你的工作副本会是这个样子的:
calc/Makefile:4
integer.c:4
button.c:5

假设此刻，Sally 提交了对 integer.c 的修改，建立修订版本 6，如果你使用 svn update 来更新你的工作副本，你会看到:
calc/Makefile:6
integer.c:6
button.c:6

Sally 对 integer.c 的改变会出现在你的工作副本，你对button.c 的改变还在，在这个例子里，Makefile 在 4、5、6 版本都是一样的，但是 Subversion 会把 Makefile 的版本设为 6 来表明它是最新的，所以你在工作副本顶级目录作一次干净的更新，会使所有内容对应版本库的同一修订版本。

2.3.4 工作副本怎样跟踪版本库

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

• 你的工作文件所基于的版本（也被称为文件的工作版本），并且
• 一个本地副本最后更新的时间戳。

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

• 未修改且是当前的
  文件在工作目录里没有修改，在工作版本之后没有修改提交到版本库。svn commit 操作不做任何事情，svn update 不做任何事情。
• 本地已修改且是当前的
  工作副本已经修改，从基准版本之后没有修改提交到版本库。本地修改没有提交，因此 commit 会成功的提交,update 不做任何事情。
• 本地未修改且过时
  这个文件在工作副本没有修改，但在版本库中已经修改了。这个文件应当更新到最新公共版本。commit 不做任何事情，update 将会更新工作副本到最新的版本。
• 本地已修改且过时
  这个文件在工作副本和版本库中都被修改了。提交 该文件将会因为 过时 而失败。该文件应该先更
  新; 更新 命令将会尝试合并公共更改和本机更改。如果 Subversion 不能顺利的自动完成合并，则需要用户解决冲突。

三、版本库

无论你用什么协议访问你的版本库，都至少需要创建一个版本库，这可以使用Subversion命令行客户端
或TortoiseSVN完成。
如果你还没有创建Subversion版本库，是时间开始了。

3.1 创建版本库

3.1.1 使用命令行工具创建版本库

1. 创建一个名为SVN(例如D:\SVN)的空文件夹，作为你的所有版本库的根。
2. 在D:\SVN\里创建另一个目录MyNewRepository。
3. 打开命令提示符(或DOS窗口)，跳转到D:\SVN\目录，输入
   svnadmin create --fs-type bdb MyNewRepository

现在你在D:\SVN\MyNewRepository创建了一个新的版本库。

3.1.2 使用TortoiseSVN 创建版本库

图 3.1. 未版本控制文件夹的 TortoiseSVN 菜单

1. 打开资源管理器
2. 创建一个新的文件夹，命名为SVNRepository
3. 右键单击 新建的文件夹并选择 TortoiseSVN → 在此创建版本库…。

然后就会在新文件夹创建一个版本库，不要手工编辑这些文件！！！如果你得到什么警告，一定要先确定目录非空并且没有写保护。
你会被询问是否要在版本库中创建目录结构。要获得关于目录结构的选项情参阅 第 3.1.5 节 “版本库布局”。
TortoiseSVN 将会在创建版本库时为其设置一个特定的文件夹图标，便于辨别本地版本库。如果使用官方的命令行客户端创建版本库则不会设置文件夹图标。

除非是基于本地测试的目的，我们推荐你完全不要使用 field:// 访问。对于除独立开发者以外的人而言，使用服务器更安全更可靠。

3.1.3 本地访问版本库

为了访问本地版本库，你需要这个文件夹的路径，只要记住Subversion期望所有的版本库路径使用的形式为file:///C:/SVNRepository/，请注意全部使用的是斜杠。
为了访问网络共享中的版本库，你可以使用驱动器影射或使用UNC路径，对于UNC路径，形式为file://ServerName/path/to/repos/，请注意这里前面只有两个斜杠。
在SVN 1.2之前，UNC路径曾经是一种非常晦涩的格式file:///\ServerName/path/to/repos，这种格式依然支持，但不推荐。

3.1.4 访问网络共享磁盘上的版本库

尽管从理论上说，将一个 FSFS 格式的版本库放在网络中共享，并且多用户通过 file:// 协议访问是可行的。但是我们不推荐这样做。事实上我们强烈反对这样做，并且不支持这样的用法基于不同得原因：

• 首先，这样赋予所有用户对版本库的写权限，所以任何一个用户都可能意外的删除整个版本库，或者因为别的问题导致版本库不可用。
• 其次，不是所有的网络文件共享协议都支持 Subversion 需要的文件锁定，所以你会发现你的版本库被毁了。它也许不会马上发生，但是总有一天会有 2 个用户同时访问版本库。
• 第三，文件的权限必需设置得井井有条。也许 Windows 的共享可以避开这个问题，但是在 SAMBA 中却是相当困难的。
• 如果有人安装新版客户端升级了版本库格式，那么其他人将无法访问该版本库，直到他们也升级到新版客户端。

file:// 访问是为本机工作而准备的，只能单用户访问，特别是测试和调试。当你打算共享版本库的时候，你真的需要设置一个适当的服务器，而且它并不像你想象的那样困难。阅读第 3.5 节 “访问版本库”获得选择指南，并配置服务器。

3.1.5 版本库布局

在将你的数据导入到版本库之前，首先你得考虑如何组织你的数据。如果你使用一种推荐的布局，你在后面的操作将会更容易许多。

有一些标准的，推荐使用的组织版本库结构的方法。大多数人创建一个 trunk 目录掌管开发的 “主干”，一个 branches 目录存放分支副本，以及一个 tags 目录存放标记副本。如果一个版本库只掌管一个项目，那么人们通常创建这些顶级录：
/trunk
/branches
/tags

因为这个布局非常通用，所以当使用 TortoiseSVN 创建版本库时，它会提出帮你创建这个目录结构。

如果一个版本库包含多个项目，人们通常按分支来安排布局:

/trunk/paint
/trunk/calc
/branches/paint
/branches/calc
/tags/paint
/tags/calc

……或者按项目:
/paint/trunk
/paint/branches
/paint/tags
/calc/trunk
/calc/branches
/calc/tags

如果项目不是密切相关，而且每一个是单独被检出，那么按项目布局是合理的。对于那些你想一次检出所有项目，或需要将它们打成一个分发包的相关项目，按分支来布局通常比较好。这种方式你只要检出一个分支，而且子项目之间的关系也比较清楚。

如果你采用顶层/trunk /tags /branches这种方式，并不意味着你必须复制整个主线为分支或标签，而且某些情况下这种结构更具灵活性。

对于不相关的项目，你可能更愿意使用不同的版本库。当你提交时，改变的是整个版本库的修订号，而不是项目的。让两个不相关的项目共用一个版本库，会导致修订号出现较大的跳跃。Subversion和TortoiseSVN项目看起来是在同一个主机地址，但是它们是在完全独立的版本库中开发着，并且版本号也不相干。

当然，你完全可以不理会上面提及的通用布局。你可以自由改变，来满足你和你团队的需要。请记住，不管你选择哪种布局，它都不是永久的。你可以在随时重新组织你的版本库。因为分支和标签是普通的目录，只要你愿意TortoiseSVN 可以将它们移动或重命名。

从一种布局转换到另一种布局仅仅是在服务器端移动一些文件或目录；如果你不喜欢版本库的组织形式，仅管大胆地修改那些目录。

因此，如果你还没有在版本库中创建基本的文件夹结构，你应该立刻创建。创建文件夹有 2 种方法。
如果你只想创建一个 /trunk /tags /branches 结构，你可以使用版本库浏览器创建这 3 个文件夹(独立的 3 次提交)。如果你想创建一个层次更深的结构，那么更简单的做法是先在硬盘中创建好文件夹结构，然后将其导入(只有 1 次提交)，就像这样：

1. 在你的硬盘上创建一个空的文件夹
2. 在那个文件夹下创建你想要的顶级目录－－千万不要放任何文件进去！
3. 将这个结构导入版本库中，只需 右键单击 包含这个结构的文件夹并选择 TortoiseSVN → 导入…。
   在导入对话框中输入版本库的 URL 并单击确定。这样就会将临时文件夹导入版本库中创建基本布局。

请注意你导入的文件夹名不会显示在版本库中，只有文件夹的内容。例如，创建如下文件夹结构:
C:\Temp\New\trunk
C:\Temp\New\branches
C:\Temp\New\tags

导入C:\Temp\New的版本库根目录，之后应该像这样：
/trunk
/branches
/tags

3.2 版本库备份

无论你使用何种版本库，定期维护和验证版本库备份非常重要，或许你可以访问最近版本的文件，但是如果没有版本库，所有的历史将会丢失。

最简单(但不推荐)的方法是复制整个版本库文件夹到备份介质，然而你必须确定没有访问进程在访问这些数据，在这里“访问”的意思是全部的任何访问。如果在复制时版本库被访问了(web浏览器，WebSVN等等)，备份将毫无意义。

• 推荐的方法是运行
  svnadmin hotcopy path/to/repository path/to/backup --clean-logs
  以一种安全的方式创建版本库的备份，然后备份副本。

svnadmin工具在安装 Subversion 命令行客户端时已自动安装。最方便的方式是在安装TortoiseSVN时勾选对应的选项，但是如果你更想要的话，可以从Subversion[https://subversion.apache.org/
packages.html#windows]网站下载最新版本命令行工具。

3.3. 服务器端钩子脚本

钩子脚本是由某些版本库事件触发的程序，例如创建新版本或修改未被版本控制的属性。每个钩子都能掌管足够的信息来了解发生了什么事件，操作对象是谁以及触发事件用户名。根据钩子的输出或者返回状态，钩子程序能够以某种方式继续执行，停止或者挂起。请参阅 Subversion 手册中的 钩子脚本
[http://svnbook.red-bean.com/en/1.7/
svn.reposadmin.create.html#svn.reposadmin.create.hooks] 章节来获得关于已实现的钩子的完整信息。

这些钩子脚本被版本库所在的服务器执行。TortoiseSVN 也允许你配置由确定事件触发，在本地执行的客户端脚本。请参看 第 4.31.8 节 “客户端钩子脚本” 以获得更多信息。

钩子脚本的例子位于版本库的 hooks 目录下。这些示例版本适用于 Unix/Linux 服务器，需要修改后才能用于Windows 的服务器。钩子可以是批处理文件或者可执行文件。下面的例子是用于版本属性更改之前 (pre-revprop-change) 的钩子。

rem Only allow log messages to be changed.
if “%4” == “svn:log” exit 0
echo Property ‘%4’ cannot be changed >&2
exit 1

注意，任何传输到标准输出 (stdout) 的内容都会被丢弃。如果想要在拒绝提交对话框中显示信息，你必须将该信息送到标准错误 (stderr)。在批处理文件中，通过使用 >&2 来实现。

跨越钩子
如果一个钩子脚本拒绝你的提交，那这就是它的最终决定。但是你可以在脚本中使用 魔 咒 来构建一种跨越机制。如果脚本要拒接操作，它首先在日志信息中扫描某个特定的通关
短语，可以是一个固定的短语或者带有某个前缀的文件名。如果它找到了魔咒则允许提交继续进行。如果没有找到则阻挡提交并返回一条消息，例如 “你没有念魔咒”。

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/笔触狂放9/article/detail/894159