虽然有点机械, 但自动的, 强制的永无遗漏地检查CVS的提交注释还是有效的.
配置CVS服务器的这一功能有一些小地方需要注意.
1. 软件版本
cvsnt: Concurrent Versions System (CVSNT) 2.5.01 (Travis) Build 1976 (client/server)
tortoise cvs: 1.8.31
WinCVS: 2.0.2.4(build 4)
2. 在CVSROOT目录下的 commitinfo 文件中, 这样指定
^Relative_Project_Path C:/ActivePerl/bin/perl.exe "D:/ABC/CVSROOT/check_comment.pl" -comment %m
这里%m 是由CVS服务器在调用perl命令行之前替换为你提供的注释
其中Relative_Project_Path 要使用/而不是\, 既使是在windows系统上. 这是个正则表达式.
3. 如果使用命令行
cvs ci -m "" file.txt
则上面的%m 不会产生一个参数. 这样 check_comment.pl 就只看到一个参数(@ARGV 只一个元素), 这在写脚本时要注意.
但命令行上使用
cvs ci -m " " file.txt
就可以使得%m 产生一个参数, 其内容为一个空格. 所以check_comment.pl 不仅要检查没有参数的情况, 还要检查参数为全空白字符(包括
换行等)的情况.
4. 但Tortoise CVS中, 仅输入空格或换行提交, CVS服务器端仍得不到%m 对应的参数. 这说明Tortoise CVS在客户端就作了处理. 同样, 下面的输出说明 Tortoise CVS的输出窗口中给出的命令行并不能直接copy到DOS 命令窗口中执行:
看绿线划出的-m 参数, 后面没有跟 "", 从命令行的角度看, MainApp.cs 会作为注释的内容而不是被提交的文件名. 不能简单地相信Tortoise CVS输出窗口中给出的命令.
上面是检查注释为空时提交失败的输出, 故意弄的醒目一些.
5. 使用WinCVS
WinCVS 会在你根本不输出注释时, 自动产生一个 "no message"作为注释送给cvs 服务器, 所以检查注释的脚本还得额外地检查WinCVS的这种纵容程序员不写注释的行为. 因为这个原因, WinCVS永远不会产生无注释的提交.
另外, 在perl脚本中*********与下面的Empty or blank... 文本之间我仅有一个空行, 但WinCVS却在处理输出时, 额外地为每行都添加一个空行. 这一点实在很恼人.
不过WinCVS会对送到标准错误输出的内容使用黄色, 这一点比Tortoise CVS好.
在既输出到标准输出, 也输出到标准错误输出时, 即使你在perl脚本中先输出到STDOUT, 再即使你还使用了$| = 1来强制刷新到设备, WinCVS还是会先显示错误消息, 之后才是送至STDOUT的消息.
如果象下面这样散布着对STDOUT, STDERR的输出:
local $| = 1;
print "STDOUT 1\n";
print STDERR "1234";
print "STDOUT 2\n";
print STDERR "xyz\n";
|
则在WinCVS的输出窗口中, 仍然是先输出所有的 STDERR消息, 然后才是 STDOUT消息. 但所有STDERR消息和STDOUT消息的相对顺序还是能保证的.
送至STDOUT的消息也是每一行额外加一个空白行.
6. 使用命令行 cvs ci file.txt
你不指定-m 注释, cvs会强制打开notepad(在windows上)让你输入注释, 不要以为看到notepad中已经有内容就可以偷懒啥也不写然后继续提交, 送至服务器端的注释仍然是空的, notepad中的既有内容仅是模板.
这说明cvs的设计者很重视开发者对每次提交都要写注释.
7. [失败经验]注意 commitinfo 中的正则表达式匹配规则: 第一个匹配成功就执行过滤程序, 其余的不检查
^Project/src/CPP
^Project/src
对第二个, 再想执行通用的检查就不行了, 因为CPP目录下的check in动作会先找到第一个匹配的条目, 执行相应的命令, 不会再继续检查其余的条目是否匹配.
阅读(940) | 评论(2) | 转发(0) |