subversion: November 2007 Archives

我以前是一个对于持续集成保持中立态度的人。因为我认为花费巨大的代价维护起来一个持续集成的体系是一个不好评估的事。原因有三：
1.大量的测试用例的书写花费巨大，我自己写过的测试用例最夸张的是源代码的200%（不过我自己早已经习惯了测试用例的书写）
2.一个持续集成的环境本身花费巨大，不同的操作系统、不同的平台、不同的用户，想要初始化一个环境就很难了，要保持一批这样的环境更是可怕
3.一但持续集成出现问题，会严重影响进度，因为大家必竟要多关心一个开发过程中的环境

看上去我的否定态度为多。我也知道它的好处，但是做为一个写了十几年代码的人，我不认为持续集成一定会给我带来什么好处。

自从重新开始代码，越来越发现持续集成的好处，当然也有现代技术进步的工具给我带来的便利，使得大家更容易的进行这个任务，同时把这样的工作成果展示出来。

今天配置好了for google codes的plugin式集成环境。狂爽ing...发现在trac里看svn中的文件是乱码，很是不爽。着手处理时看到trac的conf目录中trac.ini里有如下内容：
default_charset = iso-8859-15

为了表示对于伟大的utf-8的敬仰之情，和对于哪些偏执于陈旧帝国主义西方旧思想的回应，我把它改成了：
#default_charset = iso-8859-15
default_charset = utf-8

从此，全世界人民都开始欢呼了，统一和谐的社会到来了。 :)

我想说的只有：欢迎来到联合国！

我需要在FreeBSD中完成一个与google codes一起协作的集成环境。我需要的是这样的一个环境：
1.使用google codes的subversion
2.在本地有一个trac，这个trac跟踪svn中的更新，同时可以与相关的集成、测试环境进行协作
3.在本地有一个集成测试环境，我使用了bitten来做这个事
4.支持多个项目同时进行工作
5.使用LDAP进行用户身份验证

整体的来讲，这个系统是这样的一个其作流程：
1.用户通过svn将代码提交到google codes上的svn服务器
2.本地的服务器通过svnsync把代码同步到本机的svn库中
3.用户可以通过trac访问本机的svn库中
4.在trac中的bitten插件，得到本trac中的更新，生成了客户端们的集成和测试任务
5.客户端通过bitten客户端取得本机的集成和测试任务并且进行相关的其作，把结果发回trac
6.用户可以通过本机的trac可以知道所有的测试和集成进展

这里记下的没有理念和想法，只是把实现的系统配置说明了。主要说明的是：
1.apache安装
2.subversion安装
3.trac的安装
4.trac-webadmin的安装
5.svnsync的配置
6.svn的配置
7.trac的配置
8.trac-webadmin的配置
9.bitten的安装
10.bitten的配置