目前我们使用 FogBugz 来跟踪问题，发现没问题。我正在寻找其他可以让最终用户能够与我们一起跟踪他们的案例的东西。并且实际上适用于电子邮件的东西。我找到了一些支持这些功能的替代方案，但它们不与版本控制集成。我们在fog bugz 中有所有的SVN 钩子并且我们使用它们——但我还没有真正发现它们都那么有用。有没有人找到一个非常好的理由需要将版本控制与错误跟踪器集成？
【问题讨论】：
标签： version-control bug-tracking
显然，这种集成并不是软件运行所必需的。只要有一点纪律，每次签入都可以手动附上一个错误编号，每个错误解决都可以手动添加一个版本控制标签。
在其他条件相同的情况下，我个人更喜欢自动化而不是“用户纪律”，因为后者迟早总会不时让您失望。不是因为用户恶意或不称职，而仅仅是因为人们不能一直保持 100% 的警觉。
【讨论】：
我发现 SVN 与 TRAC 的集成非常有帮助。通过 SVN 钩子，提交到带有票据编号的存储库在票据上插入注释，并带有指向修订号的漂亮可视 HTML 表示的链接，显示插入、删除和差异。
作为一个小型程序员团队的主管，我发现这对我进行代码审查很有帮助，因此我可以验证提交是否真正解决了相关问题。我不会完全称这种集成是必不可少的，但它是我越来越喜欢的问题跟踪器上一个不错的免费附加功能。
【讨论】：
这对我们来说绝对至关重要。
这是我们一个项目的典型提交日志（示例）：
Make sure filedes is cleared in child list prior to reallocating
When p->child-filedes is > 0, the child list is active and can not
be collected.
[ Impact: Closes bug 123457 ]
请注意 [ Impact: ] 行，它也可以是“Relates-To”、“Caused”或任何数量的其他内容。
这让我们可以使用简单的 grep 和自动化脚本，允许提交者自动关闭甚至重新打开错误。
虽然我们通常使用 Git 和 Mercurial，但这类钩子（几乎）适用于任何 VCS，尤其是那些不具备您需要的某些模块化插件的专有 VCS。
如果您将错误系统视为 VCS 的另一部分，那么很容易看出它们是如何相互依赖的。
其他内容，例如获取提交的带有错误的补丁也是可能的。
【讨论】：
这是一个关于您的代码大小以及需要跟踪多少错误的问题。
它对于组织中的非编码人员也非常有用，即经理和客户支持。他们可以找到诸如“此错误何时何地修复”之类的问题的答案...
【讨论】：
我认为区分开发组织内部发现的错误很有帮助，例如来自同行代码审查，而不是由开发组织外部的测试组发现的错误。
将版本控制与外部测试组发现的错误协调起来的（小）好处是可供历史参考。
更大的好处是通过版本控制协调通过同行代码审查发现的错误 - 通过这样做，您可以在将所有代码发布给外部测试组之前证明所有代码都没有同行审查错误；一个共同的要求。
仅供参考，SmartBear, Inc. 的 Code Collaborator 很好地处理了这个问题。
【讨论】：
我发现版本控制集成对于维护和管理项目的多个版本（稳定版、开发主干版等）非常有帮助。
使用版本控制集成和编码人员的一些纪律来引用提交中的错误票据（或一些预提交挂钩来强制要求票据引用）使我们能够快速轻松地生成需要修复的变更集列表任何给定的错误。这在将修复合并到代码的各种稳定分支时很有帮助。
这不是必需品，但它确实让发布管理更轻松。
我使用 SVN + Trac 和 Atlassian 的 Jira 产品和 Fisheye SVN 插件，发现这两个工具都非常好。 Trac 似乎更简单一些，但非常易于使用。在我看来，Jira 的外观和感觉都更好，而且花里胡哨的功能更多，但有时几乎太多了。
【讨论】：