Thursday, April 20, 2006

DBIx::Class和DBI

今天在更新安装DBIx::Class 0.06001的时候,make test在测试关于cache的地方失败了。
究其原因,是因为测试cache是依赖于DBI的Trace Output的。而DBI 1.40在TraceLevel 1下,输出的内容有些问题,并且在DBI 1.43中得到了修正:
- Changes in DBI 1.43 (svn rev 377), 2nd July 2004
* Changed TraceLevel 1 to not show recursive/nested calls.

奇怪的是,在比较DBI 1.40的TraceLevel 1和TraceLevel 2的输出文件后,发现在TraceLevel 1下,输出的是recursive/nested calls的最后一句,不过这一点并没有在Changes中被提到。但是在逐版本安装测试1.42和1.43后,我确认这个问题是在1.43中修正了的。
已经把问题提交到了Dbix-class ML了,估计应该会在下一版本修正。

Saturday, April 01, 2006

如何正确设置svn仓库权限

在多用户环境下,如果你使用的是Berkeley DB作为后端,那么你多半遇到过这样的错误:
Berkeley DB error while opening environment for filesystem ...
DB_RUNRECOVERY: Fatal error, run database recovery

为了解决这个问题还是费了我不少功夫,所以这里小小地归纳一下。
首先每一个用户都需要有BDB文件的读写权限,所以通常情况下我们会创建一个用户组G,然后把所有用户都加入到G中,并且会把整个仓库的组设为G。但是,因为用户在操作BDB的时候会创建新文件,而这时使用的umask一般是022,即组用户没有写权限。此后,当其他用户试图操作该文件的时候就会发生上面的错误。
在svn的How-to文档中建议尽量避免多用户访问仓库,但是如果使用的是file:///或者svn+ssh://的话就完全没办法绕开了。于是《Version Control with Subversion》一书的第6章第5节中另外提供了一个解决方案:
$ cat /usr/local/bin/svn

#!/bin/sh

umask 002
/usr/local/subversion/bin/svn "$@"

即手动包装一下svn,在执行命令之前将umask改为002,问题就这样解决了。
svn作为新一代的版本控制系统,对于这样一个显然客观存在的问题竟然没有一个较好的解决方案,实在是令我吃惊不小。