用 Apache 和 Subversion 搭建安全的版本控制环境
参考地址：http://www.ibm.com/developerworks/cn/java/j-lo-apache-subversion/#resources
Subversion 简介

在开源软件的开发过程当中，由于开发方式自由和开发人员分散这些特性，版本控制问题一直是关系到项目成败的重要问题。没有版本控制系统的支持，开源软件的开发过程就是混乱和不可控制的。

长期以来，CVS 作为一种普遍采用的开源版本控制工具，在很多的开源软件项目当中充当了重要的角色。在 Eclipse 当中，更是把 CVS 作为一个默认的插件，与 Ant，JUnit 等工具并列在一起，成为 Eclipse 软件开发的基本工具。近年来，随着开源社区的发展，一种功能更加强大的开源版本控制工具逐渐进入了人们的视野，那就是 Subversion，凭借着更为优秀的特性，Subversion 正在逐步取代 CVS，成为新一代的开源版本控制工具。

相比 CVS，Subversion 中的目录、文件以及改名等元数据都是被版本化的，例如文件的改名、拷贝等等操作；而且，在 Subversion 中，提交操作是不可分割的，修订版本号是基于每次提交操作而非文件；另外，Subversion 可以独立运行，有着轻量级的分支（Branching）与标签（Tagging）操作，版本库可以采用数据库（Berkeley DB）或者是使用特定格式的文件进行存储，对二进制文件进行处理更为有效；最后，Subversion 工具以及相关插件都有着很好的国际化支持，可以支持包括简体中文在内的多种语言版本，方便全球各地的开发人员。这些优秀的新特性，使得 Subversion 成为开源社区目前的最佳选择。

对于普通用户，即应用程序开发者而言，尤其是对 Eclipse 的用户而言，Subversion 的使用十分的简单。通过官方提供的 Eclipse 插件 Subclipse，用户可以在 Eclipse 里面很方便的使用 Subversion 客户端的各项基本功能。具体的客户端设置和使用方法，请参考 Subversion 官方网站和 Subclipse 官方网站。简单说来，在 Eclipse 中使用 Subversion 插件的基本功能，如更新、提交、同步、分支等等，基本上同使用 Eclipse 自带的 CVS 插件一模一样，这样，用户就可以从 CVS 方便的转移到 Subversion。

目前，Subversion 已经升级到 1.3.2 版本，相关下载、特性说明和详细使用手册可以在 Subversion 主页上找到。

简单的版本库管理

有了简单易用的客户端，大部分的用户都可以轻松使用 Subversion 了，不过，作为服务器端的管理人员，还必须进一步了解服务器端的基本配置管理，才可以充分利用 Subversion 的各项优秀特性。

版本库创建

Subversion 的版本库（repository），就是位于服务器端，统一管理和储存数据的地方。本文中，我们以 Linux 为例，介绍在服务器端配置和管理 Subversion 版本库的基本方法。

要创建一个版本库，首先要确定采用哪种数据存储方式。在 Subversion 中，版本库的数据存储有两种方式，一种是在 Berkeley DB 数据库中存放数据；另一种是使用普通文件，采用自定义的格式来储存，称为 FSFS。

两种存放方式各有优缺点，读者可以参考 http://svnbook.org/ 上面的文档来了解两者详细的比较和区别，这里，我们仅引用上述文档当中的简单对照表，给出一个简明的比较。

表1 两种版本库数据存储对照表
特性 Berkeley DB FSFS
对操作中断的敏感 很敏感；系统崩溃或者权限问题会导致数据库“塞住”，需要定期进行恢复。 不敏感
可只读加载 不能 可以
存储平台无关 不能 可以
可从网络文件系统访问 不能 可以
版本库大小 稍大 稍小
扩展性：修订版本树数量 无限制 某些本地文件系统在处理单一目录包含上千个条目时会出现问题。
扩展性：文件较多的目录 较慢 较慢
检出最新代码的速度 较快 可以
大量提交的速度 较慢，但时间被分配在整个提交操作中 较快，但最后较长的延时可能会导致客户端操作超时
组访问权处理 对于用户的 umask 设置十分敏感，最好只由一个用户访问。 对 umask 设置不敏感
功能成熟时间 2001 年 2004 年

确定了具体的数据存储类型，只要在命令行当中执行 svnadmin 命令就可以创建一个 Subversion 版本库，命令如下

# 创建文件夹
$ mkdir /etc/svn/
$ mkdir /etc/svn/repos
# 运行创建版本库的命令，指定数据存储为 FSFS，如果要指定为 Berkeley DB，则将 fsfs 替换为 bdb
$ svnadmin create --fs-type fsfs /etc/svn/repos



如果一切正常，命令执行后不会有任何反馈信息而迅速返回，这样，一个新的版本库就被创建出来了。我们来查看一下生成的版本库结构：

$ ls -l /etc/svn/repos
总用量 56
drwxrwxr-x  2 robert robert 4096  8月 27 17:27 conf
drwxrwxr-x  2 robert robert 4096  8月 27 17:27 dav
drwxrwsr-x  5 robert robert 4096  8月 27 17:27 db
-r--r--r--  1 robert robert    2  8月 27 17:27 format
drwxrwxr-x  2 robert robert 4096  8月 27 17:27 hooks
drwxrwxr-x  2 robert robert 4096  8月 27 17:27 locks
-rw-rw-r--  1 robert robert  229  8月 27 17:27 README.txt



其中，conf 目录下存放了版本库的配置文件，包括用户访问控制和权限控制等内容，文件本身的注释说明十分详细，读者可以根据注释自行配置；dav 目录是提供给 Apache 相关模块的目录，目前为空；db 目录下存放着 Subversion 所要管理的所有受版本控制的数据，不同的存储方式（Berkeley DB 或者 FSFS）下有着不同的目录结构，不过我们一般不用直接修改和查看这个目录下的内容，Subversion 的命令可以安全的操作这个目录；另外，hooks 目录存放着钩子脚本及其模版（一种版本库事件触发程序），locks 目录存放着 Subversion 版本库锁定数据，format 文件记录了版本库的布局版本号。

项目添加

有了新建的版本库，就可以往里面添加项目了。不过，管理员必须考虑的问题是，应该将每一个项目分别放在不同的版本库里面，还是应该将它们放在统一的版本库里面。统一的版本库可以让管理员更加容易的升级和备份，不过，由于访问权限控制是针对整个版本库的，所以，统一的版本库也为不同项目配置不同的访问权限带来了麻烦。所以，管理员应该根据实际情况权衡考虑。

我们以统一的版本库为例，添加两个项目 project_luni 和 project_test。要做到这个，最好的办法就是用 svn import 命令导入已有的目录树。

首先，我们在一个临时目录下，根据 Subversion 版本控制的一般布局结构，创建出两个项目的主要目录树，如下：

/etc/svn/tmp
|
――project_luni
| |
| ――branches
| |
| ――tags
| |
| ――trunk
|
――project_test
|
――branches
|
――tags
|
――trunk


然后，用 svn import 命令来进行项目的导入：