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

Posted 2023-02-16

【中文标题】如何使用钩子设置和操作自定义 svn 修订属性

【英文标题】：How to set and manipulate custom svn revision property using hooks

【发布时间】：2013-04-16 20:50:47

【问题描述】：

我要配置以下内容：

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

我在第 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">空 如果 %ERRORLEVEL% EQU 0 转到 OK1

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

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

【问题讨论】：

Codereview 状态也没有意义，与文件的修订无关，已审查（你必须以某种方式存储 revision with status）

【参考方案1】：

如前所述，您必须在步骤 1 中使用 svnlook。但情况更糟：强烈不建议（而不禁止）修改交易内容在 pre-commit 钩子中以避免不可预测的结果，但您想在第 2 步中执行此操作

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

【参考方案2】：

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

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

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

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

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

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

---

现在，请原谅我在这里的肥皂盒......

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

用户是否遵循公司标准做法？ 程序中嵌入的逻辑好不好？ 开发者是否犯了一个愚蠢的错误？

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

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

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

代码审查之前：

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

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

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

代码审查后：

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

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

结果：整个团队都觉得自己无能和愚蠢。

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

怎么办？

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

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

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

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

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

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

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

【讨论】：

1.我倾向于不同意您的 CR 任务愿景和优先事项。第 2 点是最重要和最有用的部分：“不要让后辈编写糟糕但正式可构建的代码”。在这方面 Jenkins != CR（因为它无法检测代码猴子的丑陋编码风格，而且这种风格从角度来看更危险，而不是未检测到的错误）

@LazyBadger 我没有按顺序列出这些项目。我首先列出了#1，因为这是大多数 CR 浪费时间的原因。是的，#2 是最重要的，但应该在编写代码之前完成。 CI != CR，但像 Checkstyle 这样的工具可以检测代码猴子的丑陋编码风格。无需花费数小时来解决格式问题。 Jenkins 好不是因为它是 CI，而是因为它可以集成问题跟踪、单元测试、代码评估等。因为所有信息，它成为我们的开发中心。我们进行了代码审查，但重点关注我最后提到的几点。

#2（对我来说）是永无止境的过程（before-in-after coding），因为你不能从低级编码人员的角度保证代码的质量（checkstyle 仅用于样式，不是为了正确的样式，但在实现代码中很糟糕）。 #2（再次——对我来说）是在适当的用例中使用 CR 的唯一原因

谢谢大卫。我正在考虑 CR 的以下流程：

1.静态分析：在 100% 代码签入时完成。它充当看门人，通过预提交挂钩自动化。考虑到遗留代码会有很多问题，将它的代码基线化，然后只对新问题应用门禁。 2. 同行评审：有选择地进行修订（考虑到所有签到都是原子的）。出于跟踪目的，使用修订属性记录审阅状态（必需、WIP、完成）。如果有工具可用于管理同行评审工作流程，则将其配置为更新修订属性，否则手动运行脚本。

【参考方案3】：

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

svnlook.exe