11

我们正在使用 trac 并且对它非常满意。但是，开箱即用的 trac 仅适用于单项目环境。我很想听听人们为使其与多个项目一起工作而采取的各种方法以及他们在这些项目中的经验。有什么插件可以推荐吗？有任何补丁、调整或诸如此类的东西吗？您是否甚至可能使用完全不同的错误跟踪系统，该系统提供了 trac 的所有功能以及多项目支持？

我们最近开始自己管理第二个项目，它通常可以正常工作，但也有一些缺点，特别是在两个项目重叠的情况下，因为我们编写的通用库代码在两个项目中都使用。你怎么处理这个？

（我将附上我们自己当前的方法作为对这篇文章的回答。）

4

5 回答 5

10

我们采取的方法是为每个新项目创建另一个 trac 环境，并设置InterTrac链接，以便在两者之间进行更简单的交叉引用。我们还通过 [inherit] 指令使用公共基础Trac.ini文件。

除了问题中提到的共享代码的歧义问题之外，这还有一些可能会或可能不会影响您的缺点，具体取决于您的项目和工作流程的性质：

  • 创建新项目并非易事；无法通过浏览器界面完成
  • 票号不统一：每个新项目环境都从 #1 重新开始 - 至少使用 InterTrac 别名，您可以轻松消除它们的歧义
  • 安装和配置插件时必须格外小心，以便为所有环境安装和配置它们
于 2008-11-06T09:33:57.240 回答
2

我们遵循的另一种方法是将不同的项目配置为组件。

我们共享 SVN 存储库和主页 wiki 页面，但我们没有使用里程碑功能。如果项目足够大，可以有不同的模块（在我们的例子中只是其中一个），我们将每个模块配置为一个组件而不是项目。

于 2008-11-11T12:48:24.553 回答
2

大约一年前SimpleMultiProjectPlugin（在一个 Trac 实例中支持多个项目）被实施。它以 >= Trac 0.12 运行。它添加了一个新的工单字段“项目”，使用多个项目的过滤器扩展时间线和路线图页面，并将其映射到项目的版本、组件和里程碑。

于 2013-05-28T20:52:15.620 回答
1

同样的感觉，一旦正确配置，Trac 真的很棒。而且无需接触任何代码即可轻松破解。我只希望 wiki 语法更常见，比如 markdown。

我们采用了使用一个 Trac 实例的方法。我们不需要/不想使用严格的 ACL，它的好处是可以将开发人员的所有活动集中在一个地方。

对于分离项目，我们本质上是将错误分配给各种里程碑。每个项目都有一个短期和长期的里程碑。短期用于修复实际错误，长期用于主要版本。

大多数其他“新票证”字段已被修剪，保留“类型”和“严重性”字段，这在每个项目上都是相同的。

报告基本上仅限于“我的票”，并且“显示报告”按钮已经过调整以直接访问您的票。

工作流程也经过调整以添加中间“测试”状态，以便 QA 可以保证修复。

电子邮件配置已调整为不会淹没邮箱，以便开发人员实际阅读他们的作业。

有了这些，我们就有了一个非常有效的工具。花了一些时间才把它弄好，但如果你知道如何破解并在谷歌上查找东西，就很容易改变。

于 2010-04-24T19:52:02.980 回答
1

Apache Bloodhound 项目是专门启动的，目的是为 Trac 提供对多个项目的支持（除其他外）。它本质上是 Trac 之上的插件集合。

Bloodhound remains compatible with most popular Trac-Hacks and follows any changes to Trac itself. You can try the demo instance too.

于 2013-05-30T16:53:48.783 回答