Svn 来自同一用户的相同连续提交消息

我正在为我们的Subversion用户准备一些SCM指南，遇到了与团队的争论点。有没有一个有效的用例可以让某人使用相同的消息进行连续提交

如果您采取提交消息应该描述代码更改的“内容”和“原因”的方法，那么很难找到这种情况的有效案例。回顾我们的历史，发生这种情况的例子似乎比其他任何事情都更为方便，并且实际上没有讲述代码正在做什么

有人对这一点的合法性有什么看法吗？指导方针（甚至预提交挂钩）是否过于热情，或者这是一个合理的期望

---

编辑：让我们假设人们已经在留下好的提交消息。依我看，像“updated”或“typo”这样的单个单词并不能构成令人满意的提交消息。我希望看到更像“将提交按钮的颜色更新为绿色”或“在教学副本中修复打字错误”的东西。如果消息是一两个单词，那么只浏览存储库日志并了解项目中正在发生的事情而不深入到单个提交中是非常困难的。

如果我在两个不同的目录中进行相关更改（可能在项目中被广泛分离），我会这样做。这比找到一个公共根目录然后取消选择许多不相关的更改或查找我想签入的更改要容易得多。

我想这是一种技术解决方案无法解决的问题。您总是可以找到有效且工具禁止的案例，或者相反的案例

我经常使用的提交消息的一个示例讲述了所有的故事：

typo

---

最好的解决方案不是技术性的。这是社会工程。与您的团队交谈。

同一源文件上的相同提交消息。。。臭死了

---

不同源文件上的相同提交消息，连续提交：可能是ok，就像在“添加了额外日志”中一样，我通常编写非常高的抽象提交消息，因为我不太明白讲述与

diff

相同的故事的意义。这有时会导致相同的连续提交消息。

是。

---

发生这种情况的主要原因是在提交消息的使用和目的方面培训不足。定期寻找这些信息，并与做这些事情的人联系，让他们了解好的描述性提交消息的重要性，这是一个好主意。如果人们知道如何写一个好的提交消息，那么你会看到的唯一的缺点就是偶尔的心不在焉。

我不明白为什么这样不好。。。你不能每次都描述你做了什么。。。否则，你会花大部分时间用大量的文字来描述那些实际上并不重要的事情

例如：

commented here and there
typo
tidyed something ...

（我头上的例子…）

---

例如，“打字错误”意味着，如果我想写出好的提交消息，我应该用10多个字符来描述一个字母的变化。Bureocracy最优秀的形式…

我常用的是“改进日志记录”、“删除警告”等。我已经连续几天不止一次地浏览大型项目的文件，删除警告。除了“删除警告”之外，你还会在提交消息中写些什么？删除警告项目第三天早上的工作结果。或者，“删除GUI文件夹中7个左右的.c文件中的警告，这是删除警告项目的一部分”。想想你离开公司2个月后出现的那个家伙，必须返回并找出某个错误引入代码库的位置。有时，在发布完成后的几个月内，错误都不会被发现。@Michael：那个家伙只会发现错误是在试图删除警告时引入的。这是否是“警告删除项目”的“7个左右文件”签入的一部分，是否是在第三个项目的第二天，从心理学角度来看可能很有趣，但这并不意味着可怜的家伙必须调试这个问题。就我个人而言，我会把像“打字错误”这样的单个单词评论归类为不足。是的，你可以做一个区分来理解打字错误在哪里，但是只需要几秒钟就可以写出“提交按钮上的固定打字错误”，例如。这大大增强了更改日志的易读性，当然在团队环境中，有人会从中受益。