如何将事件添加到 Trac 事件时间线
我正在为 Trac 编写一个插件。 我想在每次插件从 Git post-receive hook 接收一些数据时向时间线添加一个事件。
查看 时间轴 API ，似乎您只能添加新的事件来源。 因此，您负责检索和显示数据。 我更愿意将我的事件保存到现有的源中。
我应该在 Trac API 中的哪里查找来保存事件？
ps：我的计划是依赖远程存储库和远程 Web 界面来访问代码，例如 Github。
pss：时间线必须显示主项目 git 存储库及其克隆的提交。 我不想托管对项目重要的每个存储库的副本。
I am writing a plug-in for Trac. I would like to add an event to the time line each time the plug-in receives some data from a Git post-receive hook.
Looking at the timeline API, it seems you can only add new source of events. So you are responsible for retrieving and displaying the data. I would prefer saving my event to an existent source.
Where should I look in the Trac API to save events?
ps: my plan is to rely on a remote repository and remote web interface to the code like Github.
pss: The time line has to display commits from the main project git repository and its clones. I don't want to host a copy of every repository that matter to the project.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
时间轴 API 比您需要做的要高一个级别。 ChangesetModule 中有一个通用的 VCS 实现，它将变更集（事件）检索本身委托给 VCS 特定的
存储库。 因此，您应该改为实现版本控制 API。该 API 专为“拉模型”而设计，其中 Trac 在构建时间线时查询 VCS。 如果您确实更喜欢“推送模型”（为什么？），您可以尝试使用 CacheRepository 实现 作为基础，将事件注入缓存，或者只是从头开始编写事件存储存储库。 请注意，这违背了现有设计的原则，并且很可能是不必要的额外工作。
我建议你改用普通的拉模型，它会更容易、更干净。 您可以使用Subversion 实现 或Mercurial 实现 作为参考，并且可能使用 GitPython 与
git对话。The timeline API is a level higher than what you need to do. There is a general VCS implementation of it in ChangesetModule, which delegates the changeset (event) retrieval itself to a VCS-specific
Repository. So you should implement the versioncontrol API instead.The API is designed for a “pull model”, in which Trac queries the VCS when constructing a timeline. If you really prefer a “push model” (why?), you could try working off the CacheRepository implementation as a base, injecting your events into the cache, or just writing an event-storing repository from scratch. Be aware that this goes against the grain of the existing design, and will very probably be unnecessary extra effort.
I suggest that you go with the normal pull model instead, it will be easier and cleaner. You could use the Subversion implementation or the Mercurial implementation as a reference, and probably use GitPython to talk to
git.