一、开发中的实际问题

1.1 备份
1.2 代码还原
1.3 协同修改
1.4 多版本项目文件管理
1.5 追溯问题代码的编写人员及编写时间
1.6 权限控制

二、简介

2.1 版本控制

版本控制 [Revision control]，最初来源于工程设计领域，是维护工程蓝图的标准做法，能追踪工程蓝图从诞生一直到定案的过程。是一种记录若干文件内容变化，以便将来查阅特定版本修订情况的系统。

2.2 Subversion

Subversion就是一款实现版本控制的工具软件，通常也称作是版本控制器，简称SVN。
Subversion是Apache软件基金会组织下的一个项目。

2.3 Subversion的优良特性

1. 目录版本控制

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

2. 原子提交

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

3. 版本控制的元数据

   每个文件和目录都有一组附加的“属性”，你可以发明和保存任意的键/值对， 属性也会像文件内容一样被纳入版本控制。

4. 可选的网络层

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

5. 一致的数据处理

   Subversion 使用二进制文件差异算法展现文件的区别，对于文本(人类可读)和二进制(人类不可读)文件具备一致的操作方式，两种类型的文件都压缩存放在 版本库中，差异在网络上双向传递。

6. 高效的分支和标签

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

2.4 工作原理

采取客户端/服务器模式——在服务器的版本库中保存项目文 件的各个版本，所有参与协同开发的程序员在自己本地电脑上保存一个工作副本。

SVN支持程序员将本地副本更新到服务器端的最新版本，也支持将本地副本的最新改变更新到服务器端，而且后面的更新不会覆盖前面的更新，而是作为一个新的版本被保存下来——SVN甚至支持将本地工作副本恢复为服务器端保存的某一个历史版本。

2.5 SVN基本操作

1. 检出（checkout）：将一个服务器创建好的项目下载到本地。
2. 更新（update）：将本地文件更新为服务器端的最新版本
3. 提交（commit）：将本地修改提交到服务器端。

三、Subversion的安装与配置

1. 服务器端程序版本

目前Subversion的最新版本是1.14（笔者现在的时间为2020年9月17日13:54:46）。
我这里使用的是1.8.9版本，大同小异。

2. 下载源码包

Apache 组织自己维护更新的只是 Subversion的源码，各个版本的源码包的下载地址是：http://subversion.apache.org/download/
Subversion源码是用C语言开发的。

3. 下载二进制安装包

Subversion在不同平台下的二进制包是由不同组织构建实现的，Windows平台下的二进制包实现情况在这个网页： http://subversion.apache.org/packages.html

4. 安装

找到安装文件：

我们双击这个文件：







它会在环境变量里面自动创建path：

命令控制台输入svn --version查看到信息表示服务端安装成功了。

5. 配置版本库

① 为什么要配置版本库？

Subversion 是将文件数据信息保存到版本库中进行管理的，为了满足用户的不同需求，Subversion 允许用户对版本库目录进行定制。

② 创建目录

在一个非中文无空格目录下创建一个文件夹，作为版本库的根目录： 例如：E:\Subversion\VersionRepository

③ 创建对应的子目录

在版本库根目录下创建与具体项目对应的子目录——这样做的目的是使一个 SVN 服务器能够同时管理多个项目，而不是为每一个项目搭建一个 SVN服务器——这显然太浪费资源了。
例如：
E:\Subversion\VersionRepository\AAA
E:\Subversion\VersionRepository\BBB
E:\Subversion\VersionRepository\CCC

④创建版本库

命令格式：

主命令         子命令        参数1
svnadmin      create       仓库路径

例如：svnadmin create E:\Subversion\VersionRepository\LearningSystem

⑤ 版本库目录结构

版本库创建成功后会在指定目录下产生如下的目录结构：

其中的conf是存放 版本库所使用的的配置文件的目录。
db是存放存储版本数据的数据库文件的目录。
hooks是存放版本库钩子程序的目录。
locks是存储库锁目录，用来跟踪库的访问者。
format是存储了一个整数的文件，这个整数代表库层次结构版本。
README.txt是版本库自述文件。

6. 启动服务端程序

SVN 服务器必须处于运行状态才能响应客户端请求，帮助我们管理项目文件。 所以我们必须将 SVN 服务器启动起来。启动 SVN 服务器有两种方法，一个是命令 行方式，一个是注册 Windows 服务。

① 命令行

命令格式：

svnserver -d -r E:\Subversion\VersionRepository

其中-d表示后台执行，-r表示版本库根目录，最后一个表示仓库的目录。

验证服务是否启动成功：
我们看一下现在的端口：

3690被监听的时候，就表示服务启动了。

命令行的缺陷是：只要运行服务器端程序的命令行窗口一关，服务就停止了，很不方便，而且每次开机都要手动启动。

② 注册windows服务

将SVN服务端程序注册为Windows服务，就可以让SVN服务随系统一起启动，克服了命令行方式的不足。

注册服务用的是windows的sc命令，这个是windows的命令，不是SVN的命令。

命令格式：

sc create 服务名 binpath= "***" start= auto depend= Tcpip
注意：等号的左边都没有空格，右边都有一个空格。

binpath是运行服务所需要的二进制文件路径以及运行该二进制文件的命令行参数。
start= auto表示自动启动。
depend= Tcpip表示依赖TCP/IP协议。

binpath：
其中的binpath的组成结构为：

svnserve.exe路径 参数1 参数2 参数3

---

svnserve.exe路径：SVN安装目录\bin\svnserve.exe
参数1 --service ：表示以服务方式启动Subversion
参数2 -r：表示版本库根目录
参数3 版本库目录

关于版本库的目录：
单仓库：指定与具体项目对应的仓库目录，例如E:\Subversion\VersionRepository，这样只能为一个项目服务；
多仓库：指定版本库的根目录，例如E:\Subversion\VersionRepository\LearningSystem，这样可以为了多个项目服务。

最终命令举例：

sc create MySVNService binpath= "E:\Subversion\bin\svnserve.exe --service -r E:\Subversion\VersionRepository" start= auto depend= Tcpip

注意：如果提示拒绝访问，请以管理员身份运行命令控制台：

运行结果：

我们可以在windows的服务里面看到这项了：

7. 客户端的使用

① 检出checkout

• 首先进入自己的工作目录，例如，E:\Workspaces

• 运行svn checkout命令，命令格式如下：

  svn checkout svn://SVN服务器地址/具体仓库目录 保存检出内容的目录
  

  例如：svn checkout svn://localhost/LearningSystem Learn
  结果：

• 工作副本

  运行 checkout 命令后进入 MyERP 目录，看到里面什么都没有。真的什么都没有吗？不是的。检出命令会在这一目录下创建一个隐藏目录.svn，用来保存与服务器交互的重要信息，其中包括从服务器端取回的最新版本信息、文件状态、更新时间等。SVN正是以此为依据判断当前目录中文件的状态。
  
  所以这个隐藏目录千 万不要删除或修改其中的内容——完全无视它的存在吧。如果服务器端保存的文件可以视为一个“正本”，那么每个开发人员检出到本地目录的文件可以视为“副 本”，通常称为工作副本。

② 提交

• 进入我们的工作空间，并进入我们拷贝下来的目录：
  

• 我们新建一个文件，比如：test.txt
  

• 我们执行提交命令(在本目录下)试一下：
  
  说明，一个文件，必须纳入版本控制才能可以提交到服务器端！

• 执行svn add命令，将test.txt纳入版本控制。
  

• 再次执行svn commit 命令：
  
  这是因为我们没有这次提交附加任何日志信息，这在团队开发中是极为不好的习惯！

• 使用-m 参数附加日志信息：
  
  这是因为我们没有开启权限。

• 暂时开启匿名权限
  1.进入对应的版本库目录下的conf目录下
  2.打开svnserve.conf文件
  3.将其中的# anon-access = read改为anno-access = write，也就是去掉#，并且将read改为write。注意一定要顶格写，不要留空格。
  
  不需要重启 SVN服务，甚至不需要重新打开命令行窗口。

• 重新执行提交命令
  
  这样我们就提交成功了。

  其实我们在提交的时候不需要指定具体的文件，这样就表示提交当前工作副本中。

③ 更新

• 将服务器端的文件检出到一个新的目录Learn2，模拟另一个终端：
  

• 我们回到Learn，我们对test.txt做一些修改后提交。
  
  

• 我们进入Learn目录，执行update命令：
  
  这样我们就可以在“新的目录”下看到“旧的目录”下做的更改了。

• 思考：更新和检出的相同点和不同点分别是什么？

  相同点： 从服务器端下载最新的内容
  不同点：
  检出：下载整个项目；
  更新：下载与本地工作副本不同的内容
  检出：创建.svn目录，使检出目录成为工作副本
  更新：依赖.svn目录
  检出：只能操作1次
  更新：可以操作多次

④ 工作副本的几种状态

1. 没有修改，现行版本

   本档案在工作目录中没有被修改，而且自当前版本之后，其他终端也没有任何该文件的修改被提交到服务器，即当前工作副本的版本和服务器端最新版本是一致 的。对它执行 svn commit 和 svn update都不会发生任何事。

2. 本地修改，现行版本

   这个文件被修改过，但这个修改还没有提交到服务器，而且自当前版本之后，其 他终端也没有任何该文件的修改被提交到服务器，所以当前工作副本的版本和服 务器端最新版本仍然是一致的。由于有尚未送交回去的本地修改，所以对它的 svn commit 会成功提交你的修改，而 svn update 则不会作任何事。

3. 没有修改，仓库版本

   这个文件没有修改，但是版本库中有其他终端提交的修改。此时当前工作副本的 版本比服务器端的版本落后了，我们称之为“过时”。对当前文件的 svn commit 不 会发生任何事，而 svn update 会让工作目录中的文件更新至最新版本。

4. 本地修改，过时版本

   服务器端存在没有更新到本地的修改，导致当前版本过时。如果这个文件在 本地有未提交的修改，则无法提交，对它执行 svn commit 会产生“out-of-date” 错误。 此时应该先尝试更新本地文件。更新时 SVN 会尝试将服务器端的更新与本地 文件进行合并，合并的结果有两种可能：一个是服务器端和本地修改位于文件的 不同位置，合并成功；另一个是服务器端的修改正好和本地修改位于同一个位置， 发生冲突。

⑤ 将工作副本整体回复到某一个历史版本

• 假设当前版本为12，想要取回版本9
• 执行svn update命令
  格式：svn update --revision 想要取出的版本号
  例如：svn update --revision 1
  运行：
  
• 这里需要注意的是，SVN 版本号并不是对某一个文件进行编号，而是对应整个版本库总体状态的一个“快照”，取回某个版本不是取回版本号对应的某个文件， 而是整个项目的一个快照。
  

⑥ 回复某个文件的历史状态，同时不涉及其他文件

• 假设想取回test.txt在版本2时的状态
• 执行svn update 命令