3

我想配置以下内容：

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

我在步骤 1 本身收到错误。我尝试通过添加一个预提交挂钩来检查是否设置了修订属性。我无法在预提交挂钩中执行此操作。我写了一个pre-commit.BAT文件并使用 svn propget 如下：

"C:\Program Files\Subversion\bin\svn.exe" propget "CodeReview" -t %TXN% %REPOS% >property FIND "%property%" "C:\repos\hooks\requiredproperties.txt">Null
If %ERRORLEVEL% EQU 0 转到 OK1

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

谁能帮我写三个步骤的脚本？

4

3 回答 3

2

我有一个预提交钩子，可以确保在文件提交时在文件上设置属性，并且这些属性设置为特定属性。

这将确保在提交文件时在文件上设置属性。但是，有几个问题：

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

没有一种简单的方法可以查询文件属性以查看哪些具有值，Done哪些没有。

我谦虚地提出建议：你正走向一个受伤的世界。相反，将Jenkins设置为持续构建服务器。每次有人在 Subversion 中提交更改时，Jenkins 都会启动一个构建，记录更改的内容和更改者。然后，您无需将单个文件标记为正在审查或未审查，而是验证发生在整个变更集上的 Jenkins 构建（无论如何这确实更有意义）。

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

现在，对不起，当我来到我的肥皂盒时......

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

  1. 用户是否遵循公司标准做法？
  2. 程序中嵌入的逻辑有什么好处吗？
  3. 开发者是否犯了一个愚蠢的错误？

太多的代码审查集中在问题 #1 上，而剩下的代码审查甚至开发时间很少。我花了几个小时进行代码审查，其中开发人员调用了一个变量CustomerServiceResponseCode而不是customerServiceResponseCode. 我们甚至争论过它是否应该是responseCodeCustomerService. 在我的生命中，我永远不会回来做更重要的事情，比如玩愤怒的小鸟。

至于第 2 点：这应该在编写任何代码之前完成。当开发人员花了 5 个小时编码才被告知你做错了，这有点太晚了。

现在，让我们进入第 3 点。

代码审查之前：

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

开发人员 #2：哇，是的。在我插入它之前，我忘了对动词进行混淆。男孩，这是一个愚蠢的错误。

结果：一位感到无能和愚蠢的开发人员。

代码审查后：

开发人员 #1：我们刚刚收到报告说程序中存在错误！

开发人员#2：哇，在我们插入动词之前，我们忘了对动词进行混淆。这在代码审查中是如何溜走的？

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

在批准代码之前，我很少看到真正发现错误的代码审查——即使是一个简单的错误。这是别人的代码，大多数开发人员都有其他想法。他们快速浏览了一下，发现整体逻辑看起来正确，然后为了表明他们在关注，抱怨缩进不正确。

该怎么办？

  • 作为流程的一部分，所有新的开发都应该在编写代码之前进行讨论。这不是代码审查，这是您的问题跟踪系统的一部分。

  • 使用自动化工具来捕捉事物。在 Java 中，我们有 Checkstyle（代码格式是否正确）、Findbugs、PMD（这两个工具都可以捕获潜在的错误）、复制/粘贴检测器等。Jenkins 可以运行这些程序并构建各种图表和图形。更好的是，它可以成为持续集成游戏的一部分。解决 Checkstyle 和 Findbugs 问题可以获得积分，创建新问题则会失去积分。还坚持编译器警告和弃用通知是固定的。同样，Jenkins 可以跟踪它们并给出修复和处理它们的分数。

  • 使用单元测试。当我领导一个项目时，我坚持所有的单元测试都是在创建少量代码之前编写的。这为开发人员在开发时提供了一个目标，并且代码通常更好，错误更少。使用覆盖率工具查看单元测试覆盖代码的程度。

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

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

  • 开发人员对编码有何看法？他们是否因为其他地方的设计不佳而发现实现比应有的更复杂？
  • 程序是否仍然可读和可理解？是否有太多的例外和if条款来解决实施问题？
  • 是否遵循了总体策略？开发人员在使用基类/API 时是否因为实施不当而遇到问题？
  • 开发人员是否遵循商定的逻辑？
  • 开发人员是否依赖于一个 JSON 第三方库，而您已经看到在其余代码中使用了另一个第三方库？

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

于 2013-04-16T22:48:02.717 回答
2

如前所述，您必须在步骤 1 中使用 svnlook。但情况更糟：强烈不建议（虽然不禁止）在 pre-commit 挂钩中修改事务内容以避免不可预知的结果，但您想这样做它在你的第 2 步

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

于 2013-04-16T21:55:09.643 回答
1

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

svnlook.exe
于 2013-04-16T21:42:19.150 回答