基于SVK的分布式集中版本库管理

1、版本库管理方案概述
多人团队式项目开发中，版本管理的重要性和必要性已不必多言，现在大家都已适应了版本控制的开发模式，若哪个项目没有版本管理，相信很多开发人员都会心生惶恐，不太适应了。
这里要讲述的版本管理方案对项目中的开发人员没有任何影响，他们还是会使用先前的版本控制开发模式进行项目的开发。这里要讲述的是项目的管理人员或者准确的说是公司的项目管理人员如何进行项目的版本“库”管理。当然开发人员了解并熟悉版本库的管理方案，对开发工作的版本控制也是很有好处的。
实际的项目开发中，大体有如下三种版本库管理方案：分散式、集中式、分布集中式。

A、分散式版本库管理方案
分散式版本库管理是指项目的版本库由项目自行管理，与其它项目的版本库没有任何关系，各项目的版本库形成一个个离散的孤岛。而通常项目是本地化开发，因此项目的版本库都存放在各个项目地。
这种版本库管理方案的好处是各项目地开发人员对版本库的管理有任意的控制权，这也意味着有极大的灵活性。但毫无疑问，这种版本库管理方案给公司的集中管理、规范化管理带来了很大的麻烦。事实上也加重了各项目组版本管理的负担。

B、集中式版本库管理方案
集中式版本库管理方案的指版本库集中统一管理，各项目不需考虑版本库的存储、权限控制、库结构规划等问题。简言之，各项目组基本不需考虑版本库的管理问题，版本库的管理全部交由公司统一专人管理与控制。
这种版本管理方案对公司层面要求较高，要求公司有规范的版本制度、有专业的版本管理人员，甚至还要求公司有专业的服务器设备及管理手段。
集中式版本库管理方案对网络有严重依赖。当项目地的网络出现问题时，项目的正常开发工作将受到极大影响。另外，如果网络速度较慢，也会影响项目的日常开发工作。

C、分布式集中版本库管理方案
介绍了上面的两种方案，相信聪明的读者已经明白了第三种方案所要解决的问题。是的，分布式集中版本库管理方案正是融合了”分散式管理库”和“集中式版本库”的长处，同时又避免了他们的短处。
具体来说，这种方案要求在公司建立集中的版本库，同时在项目地也建立项目版本库，通过版本库的自动同步工具保持项目地的版本库与集中版本库的自动同步。项目地开发人员日常开发访问的都是本地版本库，这样就避免了对网络的依赖，同时解决了网速慢的问题。
通常集中式版本库有严格的权限控制，同时对服务器也良好的备份管理。而各项目的版本库通常没有太多的访问权限控制；因为能自动同步，项目版本库也不要求有完善的备份机制。
当然相对于第一种方案来讲，这种方案增加了项目地版本库管理的难度，因为除了要管理本地库外，还需要管理和维护本地库与集中版本库的同步。幸运的是，现在有了SVK工具，极大降低了版本库间的同步工作难度。也正是因为有了这样的工具，“分布式集中版本库管理方案”才真正变得切实可行。

2、分布式集中库管理本管理方案实践
这里介绍的实践方案是采用基于SVK＋Subversion的方案，即项目的版本库使用和公司的集中版本库都使用Subversion来管理，两个版本库之间的同步使用SVK来实现。若项目版本库和集中版本库使用CVS，按SVK的文档介绍来看，应该也是可行的，但本人未实际使用，不敢保证其可行性。
首先介绍一下前面提到的SVK，也是本方案的核心工具，SVK是基于Subversion实现的分布式版本控制系统，通常使用SVK实现开发人员对集中式版本库的分布式和离线式访问。其典型的用法请参考SVK的官方文档，这里不详述。要特别提出的是，虽然SVK是基于Subversion实现的，但它并不要求集中版本库也是Subversion，实际上SVK是支持多种非Subversion的版本库的。
下面介绍这种方案的具体配置步骤：

A、建立集中版本库
集中版本库的建立与一般的版本库建立步骤是一样的，这里特别提醒应该注意如下几点：

* 严格的访问权限控制：可以使用SVN的访问控制机制实现；
* 用户身份验证：可以使用用户密码加数字证书的双因素认证机制，保障版本库不被非法访问，证书管理可以使用Windows Server的内建CA来实现。
* 应该有UPS保障版本服务器的不间断访问；
* 应该有完善的版本库备份机制，集中版本库应用越广，备份越重要；
* 应该提前规划好版本库的目录结构，否则后续要更改库结构会相当麻烦；
* 使用Subversion + Apache时可通过PHP实现用户密码的修改；
* 使用Subversion时可使用其hook机制实现提交时强制写日志的功能；

B、配置SVK
SVK在本方案中的作用有两点：一是用于自动进行项目地版本库与集中版本库间的同步；二是充当项目地版本库供项目日常开发使用。具体配置如下：

* 下载并安装SVK：在ubuntu环境下直接使用新立得管理工具进行SVK的安装；其它linux环境下的安装可以参考SVK官方网站的说明；Windows环境的安装需要下载SVK的相应版本并安装，但据网上的说法，SVK的Windows版本安装配置比较复杂，而且容易出问题，因此建议在Linux环境下安装SVK；
* 建立SVK版本库(SVK的术语是depot)：执行如下命令创建SVK版本库，库路径默认在当前用户目录下的.svk/local目录中；

	svk depot

* 建立本地库与集中库的映射关系：执行如下命令后将在本地库路径//remote/cscb2与集中版本库的cscb的主干间建立映射关系；

	svk mirror https://www.subverson.com/cscb/trunk2/trunk //remote/cscb2

* 建立本地版本库：上面的命令创建的//remote/cscb2库仅用于保持本地库与集中库间的映射关系，不应该被被项目日常开发所直接访问。使用如下命令创建的本地库才是项目日常开发所访问的版本库：

	svk cp //remote/cscb2 //local/cscb2

* 禁止映射库的对外访问：映射库//remote/cscb2必须禁止外部访问，否则可能破坏映射关系，导致无法进行本地库与集中库间的同步。若使用http协议访问本地库则参考svn的apache配置禁用指定路径的对外访问权限，若使用svn协议访问本地库，则可修改~/.svk/local/conf/authz文件，配置路径访问权限，参考内容如下：

	[/local]
	* = rw
	[/remote]
	* =

* 首次同步：通常集中版本库是先建立的，因此需要将集中版本库中的内容同步到本地版本库中。如果集中版本库中的版本数不多，可以采用第一条命令将集中版本库中的所有版本全部同步到本地；如果集中版本库中的版本过多，又不想在本地版本中保存过多的历史版本，则可以采用第二条命令仅同步集中版本库中指定版本开始的所有版本；

	svk sync //remote/cscb2 -- 同步所有历史版本
	svk sync -s 3145 //remote/cscb2 -- 同步集中版本库中3145以来的所有版本

* 同步本地版本库：上面的命令只是将集中库中的版本同步到了本地的映射库//remote/cscb2中，此时//local/cscb2中还没有任何版本，必须再使用如下命令将映射库内容同步到本地库中：

	svk pull //local/cscb2

* 至此项目组即可通过如下路径访问本地库：

	svn://162.16.1.22/local/cscb2

* 上述配置完成后，项目组即可在本地库中进行日常开发，但如何进行本地库的同步呢？也就是如何将集中库中的版本及时下载到本地，而本地中的修改版本又如何上传到集中库中呢？这里就要感谢SVK了，他提供了如下命令完成前述操作：

	svk sync //remote/cscb2 -- 同步集中库与本地映射库
	svk pull //local/cscb2 -- 将映射库中版本下载到本地库中
	svk push //local/cscb2 -- 将本地库中版本上传到映射库并同步到集中库中

* 为了让同步自动进行，我们可将上述命令编写到一个脚本文件中，并设定定时任务以自动执行，需要注意的是，在linux环境下自动执行上述命令时，同步到集中库的commit日志log可能出现乱码，这时需要在crontab中指定LANG=zh_CN.UTF-8以设定字符集

3、结束语
分布式集中版本管理方案为我们提供了介于离散版本库管理和集中版本库管理之间的折衷方案，在现阶段是具体较高可行性与可操作性的一种方案，值得我们偿试使用。但是由SVK还是一个非常不成熟的产品，实际使用中肯定还是会遇到各种各样的问题，这就需要各项目自已解决与取舍了。

SVK已经是停掉的项目了。

我认为任何希望在分布与集中之前取得平衡的版本管理方案实质上都是没有真正理解分布式概念的结果。文中提到所谓的分布式的缺点完全是基于错误的理解，而所谓的“分布集中”里的集中库给人以画蛇添足的感觉。

我认为分布式解决方案将会完全替代svn等中心模型。基于目前对分布式模型的实现水平上来看，很长时间内主流将只有git和mercurial。

看了邮件列表，才知道SVK的作者不再继续开发它。但不管怎样，我们实际使用了这个软件，SVK也确实给我们使用Subversion带来了方便，在此要向作者表示敬意与谢意！

我这里提到了三个版本控制方案，其实我们公司现在使用最多的是第一个方案（相信国内很多项目型的软件公司使用的也是第一个方案）。后来出于管理上的需要，我们在公司总部建立了自己的集中式版本控制系统，实际使用的体会是，从管理角度来度，集中式控制要比原来分散式控制要好得多。但因为网络、管理、成本等诸多因素的影响，这一方案在公司内部无法推行，甚至有些项目组又从集中式方案退行至分散式的第一个方案。在这样的背景下，我们找到了SVK，发现在现有的以Subversion为基础的集中式版本控制基础上，SVK能为我们带来两种方案间的平衡。因此出现了我这里所说的第三种方案，当然这不是一个纯粹“分布式”的方案，所以我将其命名为“分布式集中”方案，就是这个意思。

网上的说法是git：很好很强大，但git是否适合作为公司统一的版本控制系统呢？我想还需要在实践中检验。

svk虽然是停掉的项目，但是平时我们做项目的时候用它来同步2地的SVN仓库，还是很方便的。这里有我的一篇博文：http://blog.csdn.net/taikeqi/archive/2009/11/19/4833151.aspx