Windows下Subversion配置管理员指南

Subversion安装成service 

　之前的svnserve要想成为windows服务，必须依赖于svnservice或其余工具。从Subversion1.4开始，Subversion自己就集成Windows服务的工具。

1，安装svnservice

　在Windows NT中（包括Windows XP, Windows 2000, Windows 2003 Server）自己包含了一个安装服务的工具，叫作"Service Control"，也就是sc.exe。

例如个人Subversion安装在"D:\Subversion"，版本库在"D:\svnroot"，而我但愿对应的Subversion服务名为svnservice，安装这个svn服务的命令就能够这样写：

sc create svnservice binpath= "D:\Subversion\bin\svnserve.exe --service -r D:\svnroot" displayname= "SVNService" depend= Tcpip

请注意，由于便于察看，上面的命令分为多行，但在实际执行时应该在一行里。另外，在之前启动svnserve时会使用"-d"选项，也就是守护进程模式，在这里不能使用，会致使服务没法启动。一样，"-i"和"-t"选项也不能使用。

在命令行窗口执行完这个命令以后，服务尚未启动，你能够继续运行"net start svnservice"启动这个服务，而后使用"net stop svnservice"中止服务。

另外还有两点须要当心处理。首先，若是路径中包括空格，必定要用“\”处理“"”号，例如上面的例子中若是svnserve.exe在“c:\program files\subversion\”中，则命令应该写为“binpath= "\"c:\program files\subversion\bin\svnserve.exe\"”（“”中的内容），整个命令以下，红色部分是改变部分：

sc create svnservice binpath= "\"D:\program files\Subversion\bin\svnserve.exe\" --service -r D:\svnroot" displayname= "SVNService" depend= Tcpip

其次，sc对选项的格式还有要求，例如“depend= Tcpip”不能写为“depend = Tcpip”或“depend=Tcpip”，也就是“=”前不能有空各，然后面必须有空格。

2，删除服务

　若是服务安装的有问题，你可能须要删除服务。要删除前面添加的服务，只须要运行"net start svnservice"，"svnservice"就是咱们建立服务时使用的名字。

3，配置服务是自动启动

　默认状况下安装的服务不会随Windows的启动而启动，为了使svn服务可以随Windows启动而启动，须要修改一下"sc create"命令（首先要删除），增长"start= auto"选项：

sc create svnservice binpath= "D:\Subversion\bin\svnserve.exe --service -r D:\svnroot" displayname= "SVNService" depend= Tcpip start= auto

固然你也可使用图形化的工具修改服务的属性，你能够在“开始->运行...”中执行"services.msc"，而后在界面中修改。

Subversion的权限控制 

　1，认证（Authentication）和受权（Authorization）

　这两个术语常常一块儿出现。其中认证的意思就是鉴别用户的身份，最多见的方式就是使用用户名和密码，受权就是判断用户是否具有某种操做的权限，在Subversion里提供了“authz-db”文件，实现了以路径为基础的受权，也就是判断用户是否有操做对应路径的权限，在Subversion 1.3以后，svnserve和Apache同样均可以使用“authz-db”文件。

2. svnserve下的配置文件

　由于本文是以svnserve为例的，因此先介绍一下版本库目录的结构：

D:\SVNROOT\PROJECT1 ├─conf ├─dav ├─db │ ├─revprops │ ├─revs │ └─transactions ├─hooks └─locks

其中conf下面有三个文件：

authz passwd svnserve.conf

其中的“svnserve.conf”是这个版本库的配置文件，当使用svnserve时，这个配置文件决定了使用什么认证和受权文件：

password-db = passwd authz-db = authz

上面的配置说明使用“svnserve.conf”同目录的passwd和authz，其中的password-db指定了用户密码文件，authz-db是咱们的受权文件，也就是咱们本文主要介绍的文件。

注意：使用Apache做为服务器时，根本就不会参考“svnserve.conf”文件的内容，而是会参考Apache的配置。

3，基于svnserve的版本库文件布局

　使用svnserve时，为了管理的方便，应该使用相同的认证和受权文件，因此应该让全部版本库的配置文件svnserve.conf指向同一个password-db和authz-db文件。下面是一个多版本库的目录：

D:\SVNROOT ├─project1 │ ├─conf │ ├─dav │ ├─db │ │ ├─revprops │ │ ├─revs │ │ └─transactions │ ├─hooks │ └─locks └─project2 ├─conf ├─dav ├─db │ ├─revprops │ ├─revs │ └─transactions ├─hooks └─locks

D:\SVNROOT下有两个目录project1和project2，都已经建立了版本库，因此咱们修改每一个conf目录下的svnserve.conf，使之指向同一个password-db和authz-db文件。

password-db = ..\..\passwd

　authz-db = ..\..\authz这样，D:\SVNROOT\passwd和D:\SVNROOT\authz就控制了全部版本库的svnserve访问。另外在后面的操做中要关闭匿名访问，应该去掉“anon-access = none”前的“#”号，保证只有认证用户能够访问。

注意：还有一点须要注意，那就是svnserve的“realm”的值，在上面的设置下，应该保证全部的版本库使用相同的realm值，这样，对版本库的密码缓存能够在多个版本库之间共享，更多细节见客户端凭证缓存。

4，测试用户和组说明

　版本库禁止任何匿名用户的访问，只对认证用户有效。

root:配置管理管理员，对版本库有彻底的管理权限。

p1_admin1:project1的管理员，对project1有彻底权限。
　p1_d1:project1的开发者，对project1的trunk有彻底的权限，可是对其中的/trunk/admin目录没有任何权限。
　p1_t1:project1的测试者，对project1的trunk有彻底的读权限，可是对其中的/trunk/admin目录没有任何权限。

p2_admin1:project2的管理员，对project2有彻底权限。
　p2_d1:project2的开发者，对project2的trunk有彻底的权限，可是对其中的/trunk/admin目录没有任何权限。
　p2_t1:project2的测试者，对project2的trunk有彻底的读权限，可是对其中的/trunk/admin目录没有任何权限。

对应的组及组的用户：

p1_group_a:p1_admin1 p1_group_d:p1_d1 p1_group_t:p1_t1 p2_group_a:p2_admin1 p2_group_d:p2_d1 p2_group_t:p2_t1

5，修改D:\SVNROOT\passwd文件

前面已经说过了，用户和密码文件应该是在D:\SVNROOT\passwd，因此咱们为每一位用户设置权限，文件内容以下：

[users] p1_admin1 = p1_admin1 p1_d1 = p1_d1 p1_t1 = p1_t1 p2_admin1 = p2_admin1 p2_d1 = p2_d1

p2_t1 = p2_t1为了便于验证，全部密码和用户名一致，若是你使用的是其余认证方式，这一步可能不一样，可是用户名应该都是同样的。

6，配置受权，修改D:\SVNROOT\authz

[groups] # 定义组信息 p1_group_a = p1_admin1 p1_group_d = p1_d1 p1_group_t = p1_t1 p2_group_a = p2_admin1 p2_group_d = p2_d1 p2_group_t = p2_t1 [/] # 指定全部的版本库默认只读，root可读写 * = r root = rw [project1:/] # 指定对版本库project1根目录的权限 @p1_group_a = rw @p1_group_d = rw @p1_group_t = r [project1:/trunk/admin] # 指定对版本库project1的/trunk/admin根目录的权限， # p1_group_a读写，p1_group_d和p1_group_t没有任何权限。 @p1_group_a = rw @p1_group_d =  @p1_group_t = [project2:/] # 指定对版本库project2根目录的权限 @p2_group_a = rw @p2_group_d = rw @p2_group_t = r [project2:/trunk/admin] # 指定对版本库project1的/trunk/admin根目录的权限 @p2_group_a = rw @p2_group_d =  @p2_group_t =

通过以上设置之后，你会发现一些有趣的事情。当使用用户“p1_d1”，检出project1的trunk时，目录是空的，好像admin目录根本不存在同样，当使用p1_d1用户浏览版本库时，可以看到admin目录，可是其中的内容却没法看到。

关于中文目录，也是没有问题的，只是注意要把authz文件转化为UTF-8格式，在个人WINXP的UltraEdit里显示的文件格式为U8-DOS，具体的作法是用UltraEdit打开authz文件，而后选择“文件->转换->ASCII转UTF-8”，而后保存。

再复杂的状况也不过如此，在实际的工做中要首先规划好权限，只赋给用户最小的权限，保证以最小的配置实现最复杂的权限控制。

 

Subversion备份

　版本控制最关键的一件事是保证数据的安全性，不能由于磁盘损坏，程序故障形成版本库无可挽回的错误，为此必须制定较完备的备份策略。在Subversion中，咱们有三种备份方式：彻底备份，增量备份和同步版本库。

1, 彻底备份

　最多见和简单的备份就是直接使用拷贝命令，将版本库目录拷贝到备份目录上，就能够了。可是这样不是很安全的方式，由于若是在拷贝时版本库发生变化，将会形成备份的结果不够准确，失去备份的做用，为此Subversion提供了“svnadmin hotcopy”命令，能够防止这种问题。

还记得咱们的版本库目录吗？

D:\SVNROOT ├─project1 │ ├─conf │ ├─dav │ ├─db │ │ ├─revprops │ │ ├─revs │ │ └─transactions │ ├─hooks │ └─locks └─project2 ├─conf ├─dav ├─db │ ├─revprops │ ├─revs │ └─transactions ├─hooks └─locks

若是要把project1备份到d:\svnrootbak目录下，只须要运行：

svnadmin hotcopy d:\svnroot\project1 d:\svnrootbak\project1

可是咱们做为配置管理员，必须想办法优化这个过程，若是咱们这个目录下有许多版本库，须要为每一个版本库写这样一条语句备份，为此我写了下面的脚本，实现备份一个目录下的全部版本库。咱们在D:\SVNROOT下建立了两个文件，simpleBackup.bat：

@echo 正在备份版本库%1......
　@%SVN_HOME%\bin\svnadmin hotcopy %1 %BACKUP_DIRECTORY%\%2
　@echo 版本库%1成功备份到了%2！

这个文件仅仅是对“svnadmin hotcopy”的包装，而后是backup.bat：

echo off

rem Subversion的安装目录
set SVN_HOME="D:\Subversion"

rem 全部版本库的父目录
set SVN_ROOT=D:\svnroot

rem 备份的目录
set BACKUP_SVN_ROOT=D:\svnrootbak

set BACKUP_DIRECTORY=%BACKUP_SVN_ROOT%\%date:~0,10%
if exist %BACKUP_DIRECTORY% goto checkBack
echo 创建备份目录%BACKUP_DIRECTORY%>>%SVN_ROOT%/backup.log

mkdir %BACKUP_DIRECTORY%

rem 验证目录是否为版本库，若是是则取出名称备份
for /r %SVN_ROOT% %%I in (.) do @if exist "%%I\conf\svnserve.conf" %SVN_ROOT%\simpleBackup.bat "%%~fI" %%~nI
goto end

:checkBack
echo 备份目录%BACKUP_DIRECTORY%已经存在，请清空。
goto end

:end

你在使用的时候，只须要修改backup.bat开头的三个路径，将两个脚本拷贝到“SVN_ROOT”下就能够了。根据以上的配置，你只须要运行backup.bat，就能够把“SVN_ROOT”下的版本库都备份到“BACKUP_SVN_ROOT”里，而且存放在备份所在日的目录里，例如“D:\svnrootbak\2006-10-22”。

虽然这部分工做很简单，但是必须有人定时地去执行这个操做（例如每周一凌晨），为了不发生遗忘的状况，咱们能够将这个操做加入到系统的at任务当中去，例如仍是上面的环境，为了安装at任务，咱们运行：

at 1:00 /every:M D:\svnroot\backup.bat这样在每周一凌晨1:00都会执行这个备份过程。固然备份在本机也是不安全的，你也许须要上传到别的机器，这个就要靠你本身去实现了。

2, 增量备份

　尽管彻底备份很是简单，可是也是有代价的，当版本库很是巨大时，常常进行彻底备份是不现实的，也并没必要要，可是一旦版本库在备份之间发生问题，该如何呢，这里咱们就用到了增量备份。

增量备份一般要与彻底备份结合使用，就像oracle数据库的归档日志，记录着每次Subversion提交的变化，而后在须要恢复时可以回到最新的可用状态。在咱们这个例子中咱们使用的是，svnadmin dump命令进行增量的备份，使用方法是：

svnadmin dump project1 --revision 15 --incremental > dumpfile2

上面的命令实现了对修订版本15进行增量的备份，其中的输出文件dumpfile2只保存了修订版本15更改的内容。

为了记录每次提交的结果，咱们须要使用一项Subversion的特性--钩子（hook），看看咱们的project1目录：

├─project1 │ ├─conf │ ├─dav │ ├─db │ │ ├─revprops │ │ ├─revs │ │ └─transactions │ ├─hooks │ └─locks

其中的hooks目录里存放的就是钩子脚本，咱们在此处只使用post-commit钩子，这个钩子会在每次提交以后执行，为了实现咱们的备份功能，咱们在hooks下创建一个文件post-commit.bat，内容以下：

echo off set SVN_HOME="C:\Program Files\Subversion" set SVN_ROOT=D:\svnroot set UNIX_SVN_ROOT=D:/svnroot set DELTA_BACKUP_SVN_ROOT=D:\svnrootbak\delta set LOG_FILE=%1\backup.log echo backup revision %2 >> %LOG_FILE% for /r %SVN_ROOT% %%I in (.) do if D:/svnroot/%%~nI == %1 %SVN_ROOT%\%%~nI\hooks\deltaBackup.bat %%~nI %2 goto end :end

经过这个脚本，能够实现D:\svnroot下的版本库提交时自动增量备份到D:\svnrootbak\delta（肯定这个目录存在），其中使用的deltaBackup.bat其实能够放在任何地方，只是对脚本的svnadmin dump的包装，内容以下：

@echo 正在备份版本库%2......
　%SVN_HOME%\bin\svnadmin dump %SVN_ROOT%\%1 --incremental --revision %2 >> %DELTA_BACKUP_SVN_ROOT%\%1.dump
　@echo 版本库%2成功备份到了%3！

以上两个脚本能够直接拷贝到project2的hooks目录下，不须要修改就能够实现project2的自动备份。

以上的操做已经OK了，如今须要作的是将彻底备份和增量备份结合起来，也就是在彻底备份后清理增量备份的结果，使之只保存彻底备份后的结果。

当果然出现版本库的故障，就要求咱们实现版本库的恢复操做了，这是用要使用svnadmin load命令，同时也须要上次的彻底备份例如要把上次彻底备份backuprepo，和以后的增量备份dumpfile：

svnadmin load backuprepo < dumpfile

最后的结果，能够下载svnroot.rar，将之解压缩到d:\下，而后修改几个bat文件的SVN_HOME就可使用了。

3, 版本库同步

Subversion 1.4增长了同步机制，能够实现一个版本库同另外一个版本库的同步（但好像只是单向的），咱们能够用来实现版本库的备份或镜像。

3.1. 对目标库初始化

　svnsync init svn://localhost/project2 svn://localhost/project1 
　其中project2是目标的版本库，而project1是源版本库。其中的目标版本库必须为空，并且必须容许修订版本属性的修改，也就是在目标的版本库的hooks目录里添加一个文件pre-revprop-change.bat，内容为空便可。

3.2. 同步project2到project1

　svnsync sync svn://localhost/project2 
　这时候你update一下你的project2的一个工做拷贝，就会发现有了project1的全部内容。若是project1又有提交，这时候project2的版本库没法看到最新的变化，还须要再运行一遍sync操做，这样才能将最新的变化同步。须要注意的是，目标版本库只能作成只读的，若是目标版本库发生了变动，则没法继续同步了。

3.3. 同步历史属性的修改

　由于同步不会更新对历史属性的修改，因此svnsync还有子命令copy-revprops，能够同步某个版本的属性。

3.4. 钩子自动同步

　但愿在每次提交时同步，则须要在源版本库增长post-commit脚本，内容以下：

echo off set SVN_HOME="D:\Subversion" %SVN_HOME%\bin\svnsync sync --non-interactive svn://localhost/project2

把以上内容存放为post-commit.bat，而后放到版本库project1下的hooks目录下，这样project1每次提交，都会引发project2的同步。