我正与管理层就Subversion实践进行讨论。我已经让他们告诉管理员配置我们的Subversion存储库,以便以后可以更改提交注释,以防我错过了甚至是校对的内容: - )。
我的论点是,
缺点是,
我们的管理层拒绝了我的变更请求,原因是“管理成本增加”和“之后能够更改的风险更高”。显然我已经要求更广泛的解释了。
无论如何,你们对此有何评论?你怎么看?以后编辑日志消息是否可以?你能不能再告诉管理层了。
我认为这限制了开发人员的自由,而且正如我的开发者所希望的那样,我希望最大程度的自由发展: - )
答案 0 :(得分:2)
为了避免丢失日志消息的历史记录并添加一定级别的备份,您可以实现一个post-revprop-change钩子脚本,将日志消息属性的旧值和新值写入文件(或通过发送电子邮件,或者创建一个声音文件并让它大声拼写,以便每个人都能听到,或者......)。
这样,始终可以在文件中检查post-revprop-change钩子脚本写入并查看原始消息是什么。
答案 1 :(得分:1)
我们在工作中这样做。如果在提交之前无法检查非平凡的更改,则将"r: username (pending)"
添加到日志消息中。指定的审阅者完成后,他们会编辑日志消息以删除"(pending)"
。他们还可以在日志消息中添加其他注释。
答案 2 :(得分:1)
这是一个用例。我们有JIRA问题跟踪器。它有一个Subversion插件,它从我们的存储库加载所有subversion提交消息,并将它们与JIRA系统中的相应问题相关联。关联自动完成。我们所要做的就是在进行Subversion提交时指定问题编号。 JIRA Subversion插件解析日志消息,查看问题编号并相应地关联它们。当签到消息不包含问题编号或包含错误的问题编号时,会出现问题。需要更正此类日志消息,以便在JIRA中反映的Subversion提交是正确的。
答案 3 :(得分:0)
这完全取决于您的评论的使用方式。如果您的评论是必不可少的文档,您可以考虑创建更改日志和评论。向Web服务器提交新注释时,触发它会产生差异并将其附加到日志中。然后你就拥有了所需的所有文档,以防有人破坏重要的评论,然后恢复它们。
您还可以简单地对评论的所有编辑触发电子邮件,以便每个人都知道评论何时被编辑。如果有人做了一些不合适的事情,那就改回来吧。
答案 4 :(得分:0)
答案应该基于团队使用日志消息的频率。如果你每天使用它们,我的意思是,实际上阅读和处理它们中包含的信息,那么你应该能够改变它们。但是,如果日志消息中的注释只是存在,那么您可以回过头来查看它们,那么为什么还要能够更改它们。
我认为可能还有一个问题是你在日志消息中添加了很多信息,这些信息在bug等跟踪器或wiki等更易于访问的形式下会更好。