尝试这个:
将您的脚本复制到另一个目录并修改它以使用命令的-r
参数svnlook
而不是-t
. 然后,尝试使用应该失败的提交修订。
例如:
$ cd $repo_dir/hooks
$ cp pre-commit $HOME
$ cd
$ vim pre-commit #Change from Transaction to Revision
$ # Revision #123 should have failed
$ ./pre-commit $repo $rev
如果脚本没有产生错误,您可以尝试打印引号中的注释以查看其长度是否为零等。这将帮助您找到脚本中可能存在的逻辑错误。
您还应该在您的 Perl 脚本中使用use strict;
and use warnings;
,因为它很容易发现您在脚本中可能没有意识到的错误。很容易忘记不一定设置了特定变量,或者您输入了错误的变量。这些 pragma 会发现这些类型的错误,这些错误似乎会导致 Perl 中大约 90% 的问题:
#! /usr/bin/env perl
use strict;
use warnings;
my $svnlook = "/usr/bin/svnlook";
my $minchars = 10;
my $repos = $ARGV[0];
my $txn = $ARGV[1];
chomp ( my $comment = qx($svnlook log -t $txn $repos) );
if (not $comment) {
die "A comment is required!\n";
}
elsif ( length $comment < $minchars ) {
die "Comment must be at least $minchars characters.\n";
}
exit 0;
你也可以使用我的预提交脚本。它可以用来验证提交注释的长度和结构。例如,您可以要求提交评论需要缺陷 ID。它还允许您控制谁在存储库的哪些部分拥有提交权限,还可以强制在某些文件上使用某些属性。例如,您可能希望确保所有 shell 脚本和 Perl 脚本都svn:eol-style
设置为native
or 或LF
。
它还可以允许用户创建标签,但不允许用户在创建后对标签进行更改。这可以防止用户意外签出标签、进行更改然后提交。
还有一件事情:
看看像Jenkins这样的持续构建系统。我发现的一件事是,仅仅通过持续构建,开发人员自然而然地改进了他们的提交消息,而无需进行任何形式的强制执行。
那是因为提交消息现在很容易看到。Jenkins 显示每次构建中的更改,构建本身是否成功,测试结果等。它显示了更改和提交评论。突然之间,提交评论对开发人员自己变得更加有用,他们只是做了更好的评论。
你可以看看svn log
我什么时候实现 Jenkins:之前要么没有提交评论,要么没有诸如“重新格式化的代码”或非常有用的“进行更改”(都超过 10 个字符)之类的有用的东西。突然评论是“修正了 BUG-1233。在将它传递给 foo 方法之前检查了空指针”。