1

我已经设置了 Trac 1.0 并与我的 git repo 同步。
在使用CommitTicketUpdater并尝试使用提供的语法关闭 git commit 的问题时：“关闭 #1”或“关闭 #1”或“修复 #1”[which-did-not-work]，我不得不重置一对次分支反转我的命令提交。每次我 dd 重置时，trac 都失去了同步，我不得不重新同步：

trac-admin /path/to/project 存储库重新同步“*”

这狗屎很讨厌，需要一些时间才能完成。有什么我想念的吗？有没有办法重置分支而不是失去同步？

谢谢。

4

2 回答 2

2

Trac 和 git 在不同的范式上运行。Git 非常高兴允许您通过取消提交、重新排序修订等来更改历史记录。Trac 假设一个线性的、不可变的时间线（请记住，它是为与 Subversion 一起使用而设计的）。当您使用关闭票证的消息提交时，票证在 Trac 的数据库中关闭。当您重置提交时，Trac 不会返回并更新自己的时间线以匹配新的 git 时间线。重新同步是一个费力的过程（正如您所发现的），但这是您告诉 Trac 时间线已更改的唯一方法。

解决此问题的一种方法是让 Trac 监视与您用于开发工作的存储库不同的存储库。仅在您对 Trac 的存储库进行测试后才将更改推送到它们，并且可以相当确定您不必还原。从 Trac 的角度来看，这将使时间线保持线性，但仍允许您正常使用 git 的所有功能。

这实际上是任何系统都难以解决的问题。当您更改 git 存储库的时间线以影响使用工单打开/关闭命令（例如）的提交时，您可能会更改工单的工单编号或工单注释的顺序。这会破坏对这些项目的任何现有链接或引用。

确保您的存储库更改与您的问题跟踪器保持同步的一种方法是使用一个类似于bugs的系统，该系统将错误列表/详细信息存储在存储库中。像这样的工具通常不像 Trac 那样功能齐全，但它们的分布式特性可能更适合分布式版本控制系统。

于 2012-10-03T00:50:34.717 回答
0

为了使用 CommitTicketUpdater，我创建了一个裸存储库并向其中添加了以下钩子：https ://gist.github.com/kenaniah/5471280 （将它们放在 repo 的钩子目录中，不带 .sh 扩展名并使其可执行）。

然后我添加了一个 cron 作业来调用git fetch; hooks/post-fetch，现在无论分支结构如何，都会自动通知 trac 仅新提交。

于 2013-05-06T18:08:26.757 回答