SVN版本控制器的安装及使用方法

SVN版本控制器的安装及使用方法

一、SVN简介

1、svn全称为：Subversion，版本控制系统

​ svn是一个开放源代码的版本控制系统，通过采用分支管理系统的高效管理，简而言之就是用于多人共同开发同一个项目，实现共享资源和最终集中式的管理。

2、svn采用客户端/服务器体系，数据不丢失

​ svn是输入c/s服务类软件，有客户端和服务端，客户端用于操作，服务端用于数据存储，服务端会随着时间改变所有的数据，以递交版本记录每次操作内容。

3、svn的客户端有基于web的websvn 和 tortoise svn 为代表的客户端软件

二、SVN基本操作

操作	作用
repository（源代码库）	源代码统一存放的地方
Checkout（提取）	当你手上没有源代码的时候，你需要从repository checkout一份
Commit（提交）	当你已经修改了代码，你就需要Commit到repository
Update (更新)	当Checkout了一份源代码， Update一下就可以和Repository上的源代码同步

在日常的开发过程中操作步骤如下：

1、Update(获得最新的代码)

2、作出自己的修改并调试成功

3、Commit(大家就可以看到你的修改了)

三、SVN权限说明

​svn有一套完整的权限管理系统，可以给个人或者权限组分配权限，并且权限可以分配到文件级别，权限分为“读”和“写”。如果两个程序员同时修改了同一个文件呢, SVN 可以合并这两个程序员的改动，实际上SVN管理源代码是以行为单位的，就是说两个程序员只要不是修改了同一行程序，SVN都会自动合并两种修改。如果是同一行，SVN 会提示文件 Conflict, 冲突，需要手动确认。

四、SVN工作原理

采取客户端/服务器模式——在服务器的版本库中保存项目文件的各个版本，所有参与协同开发的程序员在自己本地电脑上保存一个工作副本。SVN 支持程序员将本地副本更新到服务器端的最新版本，也支持将本地副本的最新改变更新到服务器端，而且后面的更新不会覆盖前面的更新，而是作为一个新的版本被保存下来——SVN甚至支持将本地工作副本恢复为服务器端保存的某一个历史版本。

五、SVN客户端Subversion 安装

1、服务器端程序版本

我这边使用的是Subversionis: 1.8.17

2、下载源码包

服务器：Subversion v1.7 http://sourceforge.net/projects/win32svn/

客户端：Tortoisesvn V1.7http://tortoisesvn.net/downloads.html

3、安装

按步骤安装

• 安装程序会自动配置 Path 环境变量

​ 我这边安装的默认路径为：C:\Program Files (x86)\Subversion\bin，所以 bin 目录下的可执行文件可以在任意目录下运行。

4、验证是否安装成功

在命令行输入：

svn --version

出现如下信息就说明安装成功了。

5、配置版本库

（1）为什么要配置版本库

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

（2）在一个非中文无空格目录下创建一个文件夹，作为版本库的根目录。

例如：D:\svn\DevRepository\Subversion

（3）在版本库根目录下创建与具体项目对应的子目录

​ SVN 服务器能够同时管理多个项目，而不是为每一个项目搭建一个 SVN 服务器——这显然太浪费资源了。

（4）创建版本库

svnadmin+create+仓库路径
例如：svnadmin create D:\svn\DevRepository\Subversion\DBHelper

（5）版本库结构

文件	说明
conf	存放配置文件的目录
db	存放存储本数据的数据库文件的目录
hooks	存放版本库钩子程序的目录
locks	存储库锁目录，用来跟踪库的访问者
format	存储一个整数文件，层次结构版本
Readme.txt	版本自述文件

6、启动服务端程序

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

• 一个是命令行方式

• 一个是注册 Windows 服务

这边我主要介绍命令行方式

svnserve -d（后台执行） -r(版本库根目录) 版本库路径
例如：svnserve -d -r D:\svn\DevRepository\Subversion

验证服务是否启动

SVN 服务监听 3690 端口

1、打开一个新的 cmd 窗口

2、使用 netstat -an 命令查看 3690

查看端口是否被被监听

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

7、使用命令行模式访问 SVN 服务器

（1）提取checkout

进入自己的工作目录：D:\svn\DevRepository\DevWorkSpace\SVNSpace（自己创建）

输入命令：

svn checkout svn://SVN 服务器主机地址/具体仓库目录 保存检出内容的目录
例如：svn checkout svn://localhost/DbHelper MyDbHelper

可以看出：版本为0。

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

（2）提交commit

​ 进入D:\svn\DevRepository\DevWorkSpace\SVNSpace\MyDbHelper 目录，创建一个文件HelloSvn.txt。

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

svn add HelloSVN.txt

执行 svn commit 命令，-m 参数附加日志信息，开启匿名访问权限

进入对应的版本库目录下的 conf 目录：D:\svn\DevRepository\Subversion\DBHelper\conf ，打开svnserve.conf

​ 将第 19 行的# anon-access = read 改为 anon-access = write，也就是去掉“# ”，将 read 改为 write。注意前面不要留空格，一定要顶格写。

执行命令

svn commit -m "我的第一次提交" HelloSvn.txt

​ 其实 svn commit 命令最后可以不指定具体文件，此时表示提交当前工作副本中的所有修改。

（3）更新update

将服务器端文件提取到一个新的目录，模拟另外一个终端

回到 MyDbHelper目录，对 HelloSVN.txt 文件修改后提交

进入 TestDbHelper 目录

执行 svn update 命令

提取(cheackout)和更新(update)的区别

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

8、工作副本中文件的几种状态

①没有修改，现行版本

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

②本地修改, 现行版本

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

③没有修改，过时版本

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

④本地修改，过时版本

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

1、一个是服务器端和本地修改位于文件的不同位置，合并成功；

2、另一个是服务器端的修改正好和本地修改位于同一个位置，发生冲突。
update会让工作目录中的文件更新至最新版本。

④本地修改，过时版本

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

1、一个是服务器端和本地修改位于文件的不同位置，合并成功；

2、另一个是服务器端的修改正好和本地修改位于同一个位置，发生冲突。