我应该硬包装 SVN 提交消息吗答案

【问题标题】：Should I hard-wrap SVN commit messages我应该硬包装 SVN 提交消息吗
【发布时间】：2019-03-29 05:24:41
【问题描述】：

在 Git 用户社区中，将提交消息正文硬包装为 72-76 个字符宽度是一种广泛采用的做法；每个人都知道这一点，像“git gui”这样的工具通常会明确表示需要硬包装。但对于 SVN，情况似乎并非如此。例如，TortoiseSVN 的提交对话框完全没有给出关于包装的提示。这是否意味着最好保留未包装的提交消息？还是我应该选择自己的边界？有没有明确的权威指导？

【问题讨论】：

如果你甚至不得不考虑这一点，那你就错了：提交信息应该只有一两句话。长文本进入问题跟踪器或自述文件。
@MarnenLaibow-Koser：我可能错了，但我认为理想的提交历史必须是自给自足的。您是否尝试过从一个问题跟踪器迁移到另一个问题跟踪器？迁移后，您是否设法使所有问题 ID 和永久链接保持不变？
提交历史永远不会是自给自足的，因为它在讨论更高级别的关注点时工作在错误的粒度级别（也就是说，提交消息描述的是提交，而不是更大的内容）。这就是为什么我们首先拥有 README 文件和问题跟踪器等文档。至于您的问题，我已经在问题跟踪器之间迁移，但不是最近；但是，作为迁移的一部分，迁移脚本修复链接并不难。

标签： svn version-control tortoisesvn commit-message

【解决方案1】：

Subversion 没有针对此的全球标准/“最佳实践”。做任何对你的组织和项目有用的事情。

【讨论】：

【解决方案2】：

这真的取决于您的组织要求。

如果您正在为需要 72-76 宽度的某种类型的文档导出颠覆提交，那么您可以在团队中强制执行（甚至可能有一个正则表达式检查，您可以在 pre-commit 挂钩中编写字面上可以强制执行）。否则，我认为没有必要限制字符宽度（无论如何，svn 不会自动保持计数）。

但是，如果您只是询问最佳做法/权威指南来给您答案，您将找不到任何答案。日志消息可供您的团队解释和使用。

【讨论】：

关于预提交钩子的好点。但是，无表情地强制执行规则是不合理的：例如，Git 提交消息中的常见情况是解包长 URL。
没错，这就是为什么它可以解释的原因。你是 100% 正确的。我在挂钩中为我的组织编写了一个正则表达式，以检查是否存在某个字符串（基本上是[see #310]，因为我们希望确保每次都将某些存储库绑定到票证某些事情发生了变化。那将是强制执行以某种方式提交的正当理由。对于您的情况，这完全取决于您！:)
我会避免使用预提交挂钩来检查日志消息行宽。

【解决方案3】：

TortoiseSVN 显示了包装提交消息的提示。您需要将tsvn:logwidthmarker property 添加到您的存储库中。您还可以定义各种日志消息模板。

顺便说一句，VisualSVN 提交选择窗口也支持tsvn:logwidthmarker。

【讨论】：