用于checkstyle的Svn预提交钩子

用于checkstyle的Svn预提交钩子,svn,hook,checkstyle,pre-commit,Svn,Hook,Checkstyle,Pre Commit,这是我当前的checkstyle shell脚本。如果我在主干上提交,而不是在分支上提交,则效果很好。我真的不明白为什么它不起作用。有人能帮我吗 #!/bin/sh ################################################### # # Verify Checkstyle # ################################################### REPOS="$1" TXN="$2" SVNLOOK=/usr/bin

这是我当前的checkstyle shell脚本。如果我在主干上提交,而不是在分支上提交,则效果很好。我真的不明白为什么它不起作用。有人能帮我吗

#!/bin/sh

###################################################
#
# Verify Checkstyle
#
###################################################

REPOS="$1"
TXN="$2"

SVNLOOK=/usr/bin/svnlook
JAVA=/opt/ibm/java2-i386-50/bin/java
CHECKSTYLE=/usr/local/checkstyle/checkstyle-all-5.1.jar
TMPDIR=/tmp/$TXN
REPORT=/tmp/$TXN/report
CHECKSTYLE_CONFIG=/usr/local/checkstyle/checkstyle.xml

CHANGED=`$SVNLOOK changed -t "$TXN" "$REPOS" | grep -v "^D" | awk '{print $2}'`
mkdir -p $TMPDIR
for LINE in $CHANGED ; do
    FILE=`echo $LINE | egrep -v Test\\.java$ | egrep -v \\/src\\/test\\/ | egrep -v \\/js\\/ext`
    if [ -n "$FILE" ] ; then
        DIRNAME=`dirname $FILE`
        mkdir -p $TMPDIR/$DIRNAME
        $SVNLOOK cat $REPOS --transaction $TXN $FILE > $TMPDIR/$FILE
    fi
done
$JAVA -jar $CHECKSTYLE -c $CHECKSTYLE_CONFIG -r $TMPDIR > $TMPDIR/tmpfile.checkstyle
X=$?
if [ $X -ne 0 ] ; then
    cat $TMPDIR/tmpfile.checkstyle > /dev/stderr
    rm -Rf $TMPDIR
    exit 1
fi
rm -Rf $TMPDIR

exit 0
谢谢

提示

尝试比较创建临时目录的目录结构(删除“rm-Rf$TMPDIR”)

可能主干和分支之间存在差异,如:

主干: /tmp/12/code/file.java

分支机构:
/tmp/br1/12/code/file.java

忠告:不要将此作为预提交脚本

  • 任何预提交脚本都将保留提交直到完成。如果我签入十几个文件,这个脚本需要多长时间才能运行?当我第一次进入计算机领域时,第二次响应时间被认为是可以接受的。现在,如果你在几秒钟内没有得到回应,人们就会抱怨
  • 如果
    checkstyle
    捕捉到了不存在问题的东西,或者开发人员编写它的方式实际上比
    checkstyle
    坚持的更清晰、更容易理解,那么会发生什么情况?当您使用诸如
    checkstyle
    findbugs
    之类的工具时,您必须了解您会得到一些误报
更好的方法是使用连续构建引擎,如。Jenkins可以设置为在每次提交时自动启动构建。詹金斯可以:

  • 自动存储生成的结果。然后,您可以直接从Jenkins发布代码,用于测试和客户机。毕竟,您知道您测试的相同jar/ear/war文件与您的客户将获得的文件相同
  • 自动运行各种测试,包括:
    • 方格
    • 芬德布格斯
    • 科尔贝图拉
    • 偏振模色散
    • 干的
    • 朱尼特
    • 检查内置警告
    • 还有几十个
  • Jenkins将整个构建输出、所有保存的工件和所有测试保存在一个对任何用户都可用的漂亮且易于查看的网页中
  • Jenkins可以集成到各种各样的问题跟踪工具中,因此您可以看到Jenkins构建特定问题所涉及的内容
你不必用詹金斯。哈德逊仍然在那里。CruiseControl也是如此,您可以使用TeamCity、Bambor和其他几十个连续构建系统。我喜欢詹金斯,因为开发非常活跃,而且设置起来非常简单。当我第一次听说它时,我花了大约30分钟下载它并运行我的第一个作业


我知道你问过你的预提交钩子,我不想听起来像一个推销员(Jenkins是免费的、开源的,我与这个项目没有联系),但是做一些像
checkstyle
check这样复杂的事情是自找麻烦的。使用连续生成服务器只是处理此问题的更好方法。

我不同意。我也使用和喜欢Jenkins,但检查编码约定应该在提交完成之前完成。否则就太晚了,您的subversion差异已经被无意义的格式更改搞得一团糟。这就是为什么,在我看来,只有当代码满足您的风格要求时,才应该完成提交。如果完成一个提交需要5到10秒的时间,那么开发人员将执行更少的提交,这不是您想要的。第二种是违规的假阳性。如果代码样式检查器返回错误的冲突怎么办?你不能提交代码,或者花20到30分钟尝试咀嚼你的代码,直到工具满意为止?为开发人员提供在提交前进行检查的方法,并使用代码样式失败构建,并且有太多违规行为。反向错误提交。开发人员将学会在提交之前进行代码风格检查,这将成为您文化的一部分。首先,让提交尽可能小是一种最佳实践。检查哦,我忘记了在构建过程中进行检查的最重要的问题:提交后不能只检查修改过的文件。在现有项目中引入样式检查器时,这是一个大问题,因为开发人员不可能修复所有文件(甚至项目/包中的所有文件)。当然,您也可以将违规行为视为警告而不是错误。但是开发者会忽略这些,就像其他构建警告一样。(如果你和不同的人一起工作,你会觉得自己很幸运。)相反,我更希望开发人员只修复他修改的文件。依我看,这很简单,让老师认为应该防止恶意的犯罪行为(即使误报也是一种风险)。关于“更少的提交”,在我看来是最好的,理想情况下,我希望每个问题提交一次,而不是很多,包括所有必要的更改以克服问题,再加上与更改的错误修复相关的微小提交+10为詹金斯的推销员演讲哈哈