我们正在使用trac并且对它非常满意。但是，开箱即用，trac最适合单项目环境。我有兴趣了解人们采取的各种方法，以使其与多个项目一起工作，以及他们的经验。有推荐的插件吗？任何补丁，调整或诸如此类的东西？您是否甚至可以使用完全不同的错误跟踪系统来提供所有trac的功能以及多项目支持？
我们最近开始自己管理第二个项目，这通常可以正常工作但也有一些缺点，特别是在两个项目重叠的情况下，因为我们编写的公共库代码在两个项目中都使用。你怎么处理这个？
（我将附上我们当前的方法作为这篇文章的答案。）
答案 0 :(得分：10)
我们采用的方法是为每个新项目创建另一个trac环境，并设置InterTrac链接，以便在两者之间进行更简单的交叉引用。我们还通过[inherit]指令使用公共基础Trac.ini文件。
除了问题中提到的共享代码的歧义问题之外，这还有一些可能会或可能不会影响您的缺点，具体取决于项目的性质和工作流程：
答案 1 :(得分：2)
我们遵循的另一种方法是将不同的项目配置为组件。
我们共享SVN存储库和主页维基页面，但我们没有使用里程碑功能。如果项目足够大，可以有不同的模块（在我们的例子中只是其中一个），我们将每个模块配置为一个组件而不是项目。
答案 2 :(得分：2)
大约一年前，SimpleMultiProjectPlugin（在一个Trac实例中支持多个项目）得以实施。它以＆gt; = Trac 0.12运行。它添加了一个新的票证字段“项目”，扩展了时间线和路线图页面，其中包含多个项目的过滤器及其地图版本，组件和项目里程碑。
答案 3 :(得分：1)
同样的感觉，一旦配置正确，Trac真的很棒。而且在不触及任何代码的情况下很容易被破解。我只希望wiki语法更常见，比如markdown。
我们采用了一种Trac实例的方法。我们不需要/想要使用严格的ACL，它有利于将开发人员的所有活动集中在一个地方。
对于分离项目，我们实际上是将错误分配给各个里程碑。每个项目都有一个短期和长期的里程碑。短期用于修复实际错误和长期主要版本。
大多数其他“新票证”字段已经过修剪，保留了“类型”和“严重性”字段，这些字段在每个项目中都是相同的。
报告基本上仅限于“我的门票”，并且“显示报告”按钮已经过调整以直接访问您的门票。
工作流程也适用于添加中间“测试”状态，以便QA可以保证修复。
电子邮件配置已经过调整，不会使邮箱泛滥，因此开发人员实际上已经阅读了他们的作业。
有了这个，我们有一个非常有效的工具。花了一些时间才能做到正确，但如果你知道如何在Google上查找和查找内容，就很容易改变。
答案 4 :(得分：1)
Apache Bloodhound project专门为Trac带来了多个项目的支持（除此之外）。它基本上是Trac顶部的插件集合。
Bloodhound与最流行的Trac-Hacks保持兼容，并跟踪Trac本身的任何变化。您也可以尝试the demo instance。