post接收钩子无法在推送时更新Trac票证,同一票证有多个提交

post接收钩子无法在推送时更新Trac票证,同一票证有多个提交,trac,githooks,Trac,Githooks,有一个Trac 0.11.7环境,它使用与Git存储库集成。这个存储库有一个post-receive钩子,它是GitPlugin团队提供的钩子中的一个 当开发人员将其更改推送到服务器时,会触发post接收挂钩。如果包中每个tiket包含一条提交消息,那么一切都能正常工作——每个提交消息都与相应的票证相关联 但是,如果同一票证有多个提交,则只有最新的提交与票证关联,其余提交将出现以下错误: 处理票证ID 1时出现意外错误:列票证、时间、, 字段不是唯一的 对钩子(用python编写)进行了分析,似

有一个Trac 0.11.7环境,它使用与Git存储库集成。这个存储库有一个post-receive钩子,它是GitPlugin团队提供的钩子中的一个

当开发人员将其更改推送到服务器时,会触发post接收挂钩。如果包中每个tiket包含一条提交消息,那么一切都能正常工作——每个提交消息都与相应的票证相关联

但是,如果同一票证有多个提交,则只有最新的提交与票证关联,其余提交将出现以下错误:

处理票证ID 1时出现意外错误:列票证、时间、, 字段不是唯一的

对钩子(用python编写)进行了分析,似乎调用
票证的参数
now
的时间部分。函数
handle\u commit
中的save\u changes(eml、msg、now、db、cnum+1)
对于顺序处理的提交只相差毫秒

用于Trac的数据库是SQLite,它很可能不会将毫秒作为日期/时间类型的一部分进行处理


解决上述问题的好方法是什么?

最明显的两种方法是迁移到Trac支持的替代RDBMS(例如MySQL),或者在同一票据有多个提交的情况下,人为地在时间戳上增加一秒


后一种方法更简单,但不太严格,并且在多用户环境中可能无法很好地工作,因为开发人员的并发推送可能会导致原始问题。

为了准确克服自动提交所造成的限制,即触发的,内部Trac时间戳格式在0.12内从POSIX秒更改为POSIX微秒(自1970-01-01 0:00起)

因此,最好的解决方案是升级到Trac 0.12.3。另一种方法,正如01es所建议的那样,是把插件弄得乱七八糟。抱歉,但这只是一个黑客对黑客的攻击,不应该因为这个问题而受到指责。即使自动提交之间的最小间隔也足以让问题在您开始部署当前稳定的Trac版本时消失