目前我们使用 FogBugz 来跟踪问题，发现没问题。我正在寻找其他可以让最终用户能够与我们一起跟踪他们的案例的东西。还有一些实际上适用于电子邮件的东西。我找到了一些支持这些功能的替代方案，但它们不与版本控制集成。我们在fog bugz 中拥有所有的SVN 钩子并且我们使用它们——但我还没有真正发现它们那么有用。有没有人找到一个非常好的理由需要将版本控制与错误跟踪器集成？
问问题
1329 次
6 回答
4
显然，这种集成并不是软件运行所必需的。只要有一点纪律，每次签入都可以手动附上一个错误编号，并且每个错误解决方案都可以手动添加一个版本控制标签。
然而，在其他条件相同的情况下，我个人总是更喜欢自动化而不是“用户纪律”，因为后者迟早总会不时让你失望。不是因为用户恶意或不称职，而仅仅是因为人们不能一直保持 100% 的警觉。
于 2009-06-05T04:21:31.093 回答
1
我发现 SVN 与 TRAC 的集成非常有帮助。通过 SVN 钩子，提交到带有票据编号的存储库在票据上插入注释，并带有指向修订号的漂亮可视 HTML 表示的链接，显示插入、删除和差异。
作为一个小型程序员团队的主管，我发现这对我进行代码审查很有帮助，因此我可以验证提交是否真正解决了相关问题。我不会完全称这种集成是必不可少的，但它是我的问题跟踪器上一个很好的免费附加功能，我已经爱上了它。
于 2009-06-09T02:07:59.907 回答
1
这对我们来说绝对至关重要。
这是我们的一个项目（示例）的典型提交日志：
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 的另一部分，那么很容易看出它们是如何相互依赖的。
其他的东西，例如获取带有错误提交的补丁也是可能的。
于 2009-06-09T03:09:05.230 回答
0
这是一个关于您的代码大小以及需要跟踪多少错误的问题。
它对组织中的非编码人员也非常有用，即经理和客户支持。他们可以找到诸如“此错误何时何地修复”之类的问题的答案......
于 2009-06-05T04:40:01.477 回答
0
我认为区分开发组织内部发现的错误（例如来自同行代码审查）与开发组织外部的测试组发现的错误是有帮助的。
将版本控制与外部测试组发现的错误协调起来的（小）好处将是历史参考。
更大的好处是通过版本控制协调通过同行代码审查发现的错误——通过这样做，您可以在将所有代码发布给外部测试组之前证明所有代码都没有同行审查错误；一个共同的要求。
仅供参考，SmartBear, Inc. 的 Code Collaborator 很好地处理了这个问题。
于 2009-06-05T04:40:48.433 回答
0
我发现版本控制集成对于维护和管理项目的多个版本（稳定版、开发主干等）非常有帮助。
使用版本控制集成和编码人员的一些纪律来引用提交中的错误票（或一些预提交挂钩以强制要求票参考）使我们能够快速轻松地生成修复任何给定错误所需的变更集列表. 这在将修复合并到代码的各种稳定分支时很有帮助。
这不是必需品，但它确实使发布管理的工作更轻松。
我使用了带有 Fisheye SVN 插件的 SVN + Trac 和 Atlassian 的 Jira 产品，发现这两个工具都非常好。Trac 似乎更简单一些，但非常易于使用。在我看来，Jira 有更好的外观和感觉，还有更多的花里胡哨，但有时几乎太多了。
于 2009-06-09T04:22:10.683 回答