什么构成有效的SCM消息？

Question

我正在为一个新的SVN实例编写一些钩子，我想要一些反馈，他们认为应该应用什么标准来验证提交消息是否足够。这个特定的SVN实例将被广泛的开发人员使用，他们对SCM最佳实践有不同的了解。

我正试图在强制充分的信息来正确描述变化之间取得良好的平衡，但不要变得过度热心，并使那些拥有简洁但完全有效的信息的人生活困难。我试图拒绝的事情是“更新”或“添加文件”等消息，因此对字数和消息长度的限制是显而易见的选择。

您会使用哪些其他标准来拒绝未正确描述更改的邮件？请保持回复的重点是如何获得满意的信息;我非常清楚社会对教育的需求，这种情况正在同时发生。

顺便说一句，在这种特殊情况下，不必担心对工作项或错误的引用。

Answer 1

老实说，我认为任何特定标准作为一项硬性要求绝对毫无价值。如果你曾经见过一个网站，在评论/评论中需要最少数量的字符（dealextreme，甚至可以想到这个网站），你很快就会意识到效果并不是你想要的。而不是人们确保评论和评论更长，他们只会找到更多的填充物，以确保它们达到已知和硬编码的最小值。

最终，问题必须作为社会问题而不是技术问题来处理。每个不恰当无效的评论的实例都需要引起做这件事的人的注意并向他们解释。

这仍然不能100％解决问题，但它是我找到的最接近工作的方法。

说完这一切之后，如果有人能用少于40个字符编写一致好的cvs评论，我会感到非常惊讶。 ：）

Answer 2

我同意其他答案。不愿意合作的人总会找到解决问题的方法。

然而，我一直在做的事情如下：

• 设置预提交钩子以检查是否提供了评论（即，提交消息不为空），只是为了防止人们（包括我自己）“意外”忘记提供评论。不过不要对提交消息的内容进行任何检查;这是浪费时间。
• 放置一个pre-revprop-change挂钩以允许之后编辑提交消息（默认情况下不允许）

Answer 3

我同意其他答案，即此时的验证不会100％有效。但进行一些验证将有助于实现部分合规。

因此我建议如下：

• 具有最低数量的角色要求。根据收集的调查结果确定合适的数字。
• 列出一些可能不可接受的关键短语。注意不要包含可以接受和不可接受的词语，如“更新”。
• 在级联SVN提交策略时强调规则 确定一个非常好的媒介来定位用户。

我相信规则会最大限度地减少不合规用户的出现，但不能完全消除它们。

希望这有帮助。

Answer 4

这可能不会让你受益匪浅。如果你拒绝“更新”，那么人们就会做出让他们提交的内容。“为saldkj dot quux添加了一个新的fizzleglorb。”社会问题的技术解决方案不起作用。

另外，也许可以考虑像Git这样的工具，以便您可以合并相关的提交。当你处于黑客攻击阶段时，你不想写一个详细的消息。但是当你回去审查你的工作并将其压缩成一个逻辑块时，那就是你想要添加关于你正在做什么的文档。

Answer 5

我发现要求至少15个字符（不包括空格）的效果相当不错。不要试图通过更精细的检查来过度使用它。设置提交邮件列表也会有所帮助;它宣传了很好的例子并增加了社会控制。

总会有一些开发人员将其作为挑战，以尽量减少提交消息中的任何有用信息。但是，如果我在之前查看SVN日志（90％为空）和之后（80％有点有用）安装了预提交钩子，我得出结论，这里的情况有所改善。