Question

我想配置以下内容：

当开发人员从他们的SVN客户端签入代码时，钩子应该验证它是否设置了修订属性“CodeReview”以及属性值（如果已设置）。
如果未设置，则添加revision属性并将其值设置为“Not Done”
完成代码审核后，将属性值更新为“完成”。

我在第1步发现错误。我尝试添加一个预提交钩子来检查是否设置了revision属性。我无法在预提交挂钩中执行此操作。我写了一个pre-commit.BAT文件并使用了svn propget，如下所示：

“C：\ Program Files \ Subversion \ bin \ svn.exe”propget“CodeReview”-t％TXN %% REPOS％＆gt; property   找到“％property％”“C：\ repos \ hooks \ requiredproperties.txt”＆gt; Null
  如果％ERRORLEVEL％EQU 0转到OK1

这会产生错误 - 抱怨-t。

任何人都可以帮我处理这三个步骤的脚本吗？

Answer 1

如前所述，您必须在步骤1中使用svnlook。但情况更糟糕：强烈不推荐（而未禁止）修改交易内容在预提交钩子中，以避免不可预测的结果，但你想在你的第2步

而且，JFYI，属性（任何 svn属性）是文件或目录的属性，您试图从事务中获取，这将是永远不会成功

Answer 2

我有一个pre-commit hook，可以确保在文件提交时设置属性，并将这些属性设置为特定属性。

这将确保在文件提交时对属性进行设置。 HOWEVER ，有几个问题：

文件属性与文件一样被修改。如果我在修订版14上为我的文件设置了属性CodeReview = Done，则当下一个人将其更改提交到Subversion时，它将设置为CodeReview = Done。不完全是你想要的。

查询文件属性并不是一种简单的方法，可以查看哪些文件属性的值为Done，哪些文件属性为“{/ 1}}。

我谦卑地提出建议：你正在进入一个受伤的世界。相反，将Jenkins设置为连续构建服务器。每次有人在Subversion中进行更改时，Jenkins都会触发 build 记录变更内容以及由谁更改。然后，不是将单个文件标记为已审核或未审核，而是验证在整个变更集上发生的Jenkins构建（无论如何真正更有意义）。< / p>

您可以使用Promoted Build Plugin标记特定版本是否已经过审核，以及是否通过了代码审核。您还可以在每个构建中附加对代码审查中发现的任何问题的评论。

现在，对不起，我在这里上了肥皂盒......

大多数代码评论都毫无价值。代码审查有三个主要方面：

用户是否遵循公司标准惯例？
程序中嵌入的逻辑是否有用？
开发人员是否犯了一个愚蠢的错误？

太多的代码评论专注于问题＃1，并且剩下很少的时间用于其余的代码审查甚至开发。我在代码审核中花了好几个小时，开发人员称之为变量CustomerServiceResponseCode而不是customerServiceResponseCode。我们甚至认为它应该是responseCodeCustomerService。我生命中的几个小时我永远不会回去做更重要的事情，比如玩“愤怒的小鸟”。

关于第2点：在编写任何代码之前，应该。当开发人员用5个小时的编码告诉你做错了时，有点太晚了。

现在，让我们来点＃3。

在代码审核之前：

开发人员＃1：嘿，你的程序中有一个错误！

开发者＃2：哇，是的。在我插入它之前，我忘记了fbeberbrate the verbex。男孩，这是一个愚蠢的错误。

结果：一位感觉无能和愚蠢的开发者。

代码审查后：

开发人员＃1：我们刚收到一份报告，说该程序中存在错误！

开发人员＃2：哇，我们在插入它之前忘记了fbeberbrate verbex。在代码审查中这是怎么回事？

结果：整个开发团队感到无能和愚蠢。

在批准代码之前，我很少看到实际捕获错误的代码审查 - 即使是简单错误。它是别人的代码，大多数开发人员都有其他想法。他们快速查看，看看整体逻辑看起来是正确的，然后表明他们正在关注，抱怨缩进是不正确的。

怎么办？

作为流程的一部分，应在编写代码之前讨论所有新开发。这不是代码审核，这是您的问题跟踪系统的一部分。
使用自动化工具捕获内容。在Java中，我们有Checkstyle（正确的代码格式），Findbugs，PMD（两个工具捕获潜在的错误），复制/粘贴检测器等.Jenkins可以运行这些程序并构建各种图表和图形。更好的是，它可以成为持续集成游戏的一部分。你可以获得解决Checkstyle和Findbugs问题的积分，并因创建新问题而失去积分。还要坚持修复编译器警告和弃用通知。同样，Jenkins可以跟踪它们并给出修复它们并处理它们的要点。
使用单元测试。当我领导一个项目时，我坚持要在创建一些代码之前编写所有单元测试。这为开发人员提供了在开发时达到目标的目标，并且代码通常更好，错误更少。使用覆盖工具查看单元测试对代码的覆盖程度。

使用自动化工具通常会捕获比手动代码审查更多的错误。自动化测试可以检测代码逻辑何时可能存在问题。

这并不意味着代码审查毫无用处。它只是允许代码审查是代码的整体审查。例如：

开发人员对编码的看法是什么？他们是否因为其他地方设计不佳而发现实施工作比以前更复杂？
该程序是否仍然可读且易懂？是否有太多例外和if条款来解决实施问题？
是否采用了一般策略？由于实现不好，开发人员是否因使用基类/ API而出现问题？
开发人员是否遵循商定的逻辑？
开发人员是否依赖于说一个JSON第三方库，并且您已经看到其他代码中使用了另一个第三方库？

不要为了代码审核而进行代码审核。不要在代码审查的实施上浪费太多时间。而且，为了上帝自己的利益，不要进行预先提交代码审查。这意味着开发人员在完成任何工作之前都会等待批准。

Answer 3

您不能使用svn.exe，因为它不支持-t选项。你应该使用

svnlook.exe

如何使用钩子设置和操作自定义svn修订版属性

3 个答案:

在代码审核之前：

代码审查后：