2

我正在与管理层讨论 Subversion 实践。我已经要求他们告诉管理员配置我们的 Subversion 存储库，以便之后可以更改提交评论，以防我错过了校对 :-)。

我的论点是，

  • 可以更改需要改进的日志消息，例如更广泛的评论或拼写错误。
  • 输入日志消息时很容易出错，这样可以恢复它们。
  • 当犯错时，每个人都应该有第二次机会:-)
  • 如果将源代码和注释从存储库导出到第三方，如果发现不正确的日志消息，这将是有价值的。如果无法更改或仅在导出的文本文件中更改注释，则所有内容都将变得不同步。

缺点是，

  • 日志消息更改本身不会被验证，因此旧消息显然丢失了。

我们的管理层拒绝了我的变更请求，因为“增加了管理成本”和“之后能够进行变更的风险更高”。显然，我要求进行更广泛的解释。

无论如何，你们对此有什么意见吗？你怎么看？之后可以编辑日志消息吗？你能给我更多的专业人士告诉管理层吗？

我认为这限制了开发人员的自由，作为我的开发人员，我希望最大程度的自由茁壮成长 :-)

4

5 回答 5

2

为避免丢失日志消息的历史记录并添加某种级别的备份，您可以实现post-revprop-change挂钩脚本，将日志消息属性的旧值和新值写入文件（或通过电子邮件发送，或创建一个声音文件并让它大声拼出更改让每个人都能听到，或者......）。

这样，始终可以检查 post-revprop-change 挂钩脚本写入的文件并查看原始消息是什么。

于 2009-12-10T09:25:01.177 回答
1

我们在工作中这样做。如果您在提交之前无法审核重要的更改，则添加"r: username (pending)"到日志消息中。指定审阅者完成后，他们编辑日志消息以删除"(pending)". 他们还可以在日志消息中添加其他评论。

于 2009-12-10T08:01:10.523 回答
1

这是一个用例。我们有 JIRA 问题跟踪器。它有一个 Subversion 插件，可以从我们的存储库中加载所有 subversion 提交消息，并将它们与 JIRA 系统中的相应问题相关联。关联是自动完成的。我们所要做的就是在提交 Subversion 时指定问题编号。JIRA Subversion 插件解析日志消息，查看问题编号并相应地关联它们。当签入消息不包含问题编号或包含错误的问题编号时，就会出现问题。需要更正此类日志消息，以便在 JIRA 中反映的 Subversion 提交是正确的。

于 2009-12-10T08:14:38.020 回答
0

这完全取决于您的评论是如何被使用的。如果您的评论是必不可少的文档，您可以考虑创建变更日志 og 评论。当向网络服务器提交新评论时，触发它产生差异并将其附加到日志中。然后你就有了你需要的所有文档，以防有人破坏重要的评论，以恢复它们。

您还可以简单地使所有评论编辑触发电子邮件，以便每个人都知道评论何时被编辑。如果有人做了不好的事情，就把它改回来。

于 2009-12-10T08:29:52.410 回答
0

答案应该基于团队使用日志消息的频率。如果您每天都在使用它们，我的意思是，实际阅读和处理其中包含的信息，那么您应该能够更改它们。但是，如果日志消息中的注释只是在那里，以便您偶尔可以回去查看它们，那么为什么还要麻烦能够更改它们。

我认为可能还有一个问题是您将大量信息放入日志消息中，这会以更易于访问的形式（如错误跟踪器或 wiki）更好。

于 2009-12-10T08:42:25.977 回答