SVN与Bug跟踪/票务软件的集成

Question

我想知道是否有任何软件，集成票务系统(或错误跟踪)与SVN，但在一个特定的方式。我希望禁止任何没有票证(或bug id)的代码更改。

例如：

1. 每个开发人员都有对SVN的只读访问--他可以更新源代码，但不能提交。
2. 每次提交都必须包含Bug/票证id
3. 即使对于优化任务，开发人员也必须为自己创建票据，然后实现一些东西。

我知道有一些工具，比如Mylyn，有助于票务系统/SVN集成，但是开发人员总是可以提交源代码。

我没有任何用于票务系统的环境(我可以使用Trac以及BugZilla或任何其他环境)，但是必须使用SVN作为代码存储库。

您对如何以这种方式集成这些服务有什么想法吗？

Answer 1

对于这种策略，您必须编写一个Hook脚本，它检查日志消息中是否有票证id，当然还必须检查票证id是否属于适当的项目。此外，您还可以使用诸如雷德明之类的东西作为票证系统。

Answer 2

我最近一直在使用TFS。它具有设置类似工作流的能力--您必须创建“工作项”，您可以将bug附加到其中，并向其提交更改。不首先创建bug，不首先创建工作项，就不可能提交。

这让我抓狂，我改变了设置，因为我的工作流程是这样的：

• 很高兴地编辑代码来修复一个bug。
• 找出另一个无关的窃听器。
• 将代码更改提交给第一个bug。
• 停止流并启动工作项编辑器。
• 找出UI 2010可怕的工作项UI，并创建一个新的工作项。
• 找出new 2010可怕的bug跟踪器，并创建一个新的bug。
• 回到密码。
• 找出第二个bug在哪里。
• 修复第二个窃听器。
• 回到原来的bug上。

实际上，我的工作流程更像这样：

• 很高兴地编辑代码来修复一个bug。
• 找出另一个无关的窃听器。
• 想一想，“修复这一行代码将花费我一个小时的时间摆弄迟钝的bug跟踪器，去他的。”
• 继续对原来的错误进行处理。

总体效果是，我本可以在任何时间内修复的bug仍然存在于系统中，因为我不会把时间浪费在荒谬的官僚主义错误报告系统上。对你来说，更重要的是什么--快乐、高效的开发人员，还是从SVN中提取出来的令人印象深刻的报告？

Answer 3

如果你真的想要的话，你可以看看嘎嘎声，乌龟的插件，它允许用户弹出一个bugz列表。遵循该模板，您可以提供一种方法，以便在没有案例/问题的情况下快速轻松地创建一个案例/问题。

除了我不得不说的外，我认为你的目标是错误的，而且适得其反。有些善意的过程/政策有时听起来不错，但实际上却是一场噩梦，浪费了时间和资源。这是浪费时间和糟糕过程的一个很好的例子。