显然,这种集成并不是软件运行所必需的。通过一点纪律性,每次检查都可以手动附上一个错误编号,每个错误解决方案也可以手动添加版本控制标签。
其他条件相等的情况下,我个人总是更喜欢自动化而不是“用户的纪律性”,因为后者迟早会让你失望。这并不是因为用户恶意或无能,而仅仅是因为人们不能始终保持100%的警觉。
这对我们来说绝对至关重要。
以下是我们项目之一的典型提交日志(样例):
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 ]
我认为将SVN与TRAC集成非常有帮助。通过使用SVN钩子,将包含票号的提交插入到存储库中,可以在工单上插入注释,并链接到漂亮的HTML修订号视图,显示插入、删除和差异。
作为一个小团队程序员的主管,我发现这是一个有用的工具,可以帮助我进行代码审查,以验证提交是否真正解决了相关问题。我不会完全称之为必要的集成,但它确实是我喜欢的免费额外功能。
这是关于您的代码大小以及需要跟踪多少个错误的问题。
对于组织中的非编码人员,如经理和客户支持,这也非常有用。他们可以找到答案,例如“何时何地修复了此错误”...
我认为区分开发组织内部发现的错误(例如来自同行代码审查)和由测试组发现的错误是有帮助的。
将版本控制与外部测试组发现的错误协调起来的(小)好处在于历史参考。
更大的好处在于将通过同行代码审查发现的错误与版本控制协调起来 - 这样做可以确保在将代码发布给外部测试组之前,所有代码都经过同行审查并且没有错误;这是一个常见的要求。
顺便说一下,SmartBear公司的Code Collaborator可以很好地处理这个问题。
我发现版本控制集成在项目中的维护和管理多个版本(稳定版、开发版等)非常有帮助。
使用版本控制集成并要求程序员遵循纪录 bug 票据的提交规范(或使用一些预提交钩子来强制要求票据引用),可以让我们快速轻松地生成所需更改集合的列表,以修复任何给定的 bug。这在将修复合并到代码的各个稳定分支时非常重要。
这不是必须品,但对于发布管理来说肯定会使生活更轻松。
我使用过 SVN + Trac 和 Atlassian 的 Jira 产品与 Fisheye SVN 插件,发现两款工具都非常好。Trac 看起来更简单,但非常易于使用。在我看来,Jira 的外观和感觉更好,并且有更多吸引人的功能,但有时几乎太多了。