【问题标题】:SVN integration with Bug tracking/ticketing softwareSVN 与错误跟踪/票务软件的集成
【发布时间】:2011-01-04 14:49:05
【问题描述】:

我想知道是否有任何软件可以将票务系统(或错误跟踪)与 SVN 集成,但以特定方式。我想禁止任何没有票证(或错误 ID)的代码更改。

例如:

  1. 每个开发人员都拥有对 SVN 的只读访问权限 - 他可以更新源,但不能提交。
  2. 每个提交都必须包含错误/票证 ID
  3. 即使是优化任务,开发者也必须自己创建票证,然后实现一些东西

我知道有一些像 Mylyn 这样的工具可以帮助票务系统/SVN 集成,但开发人员始终可以提交源代码。

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

您对如何以这种方式集成这些服务有任何想法吗?

【问题讨论】:

  • 该政策的具体目的是什么?似乎它只会创造繁忙的工作——如果人们遵守它,制定政策和审查会比强制一些严格的规则更好吗?最终你会得到一堆没有内容的无用的、空的案例/问题/错误——它们的存在只是为了一个参考号,所以有人可以向存储库提交一些东西。您只是将问题从一个地方转移到另一个地方,并在此过程中造成混乱。
  • 嗨,蒂姆,是的,你是对的,但是在只维护项目的情况下,开发团队的工作主要是创建小型附加组件和解决错误。在这种情况下,将错误和相应的代码更改放在一个地方可能是个好主意。
  • 您可以非常轻松地集成,我认为这是一个好主意 - 我在所有项目和工作中都使用它,但问题在于“禁止任何代码更改”。这听起来是个非常糟糕的主意。
  • 是的,事实上确实如此。但是,在我的方法中,我总是需要从需求到代码以及相反方向的链接。为了确保这一点,我需要禁止代码更改(没有票证),因为不会有这样的连接。
  • 这也是没用的,因为即使你在 svn 端有钩子,用户也可以输入一个旧的/不相关的票号来进行提交。同样,您并没有真正以这种方式解决任何问题。答案是教育您的开发人员并使您的流程正常运行,而不是制定一些不可动摇的规则。

标签: svn integration ticket-system


【解决方案1】:

对于这种策略,您必须编写一个 Hook 脚本来检查日志消息中是否有票证 ID,当然还要检查票证 ID 是否属于适当的项目。此外,您可以使用 Redmine 之类的东西作为票务系统。

【讨论】:

  • 是的,这几乎就是我一直在寻找的。我认为最简单的方法是找到 IBugtraqProvider SVN 接口 (tortoisesvn.net/docs/release/TortoiseSVN_en/…) 的正确实现。我会花一些时间尝试一些问题跟踪器。感谢您的提示。
  • 很抱歉,您必须在服务器端而不是在客户端实现 Hook 脚本。
  • 是的,我想就是这样。我发现了几个 SVN 插件和教程如何创建谷歌的钩子脚本。在我看来,这回答了我的问题。现在我必须做一些试验,让 svn 和票务软件一起工作。谢谢!
【解决方案2】:

我最近一直在使用 TFS。它有能力建立一个类似的工作流程——你必须创建“工作项”,你可以将错误附加到这些工作项上,你可以提交更改。如果不先创建错误,不先创建工作项,就不可能提交。

这让我发疯了,我更改了设置,因为我的工作流程是这样的:

  • 愉快地编辑代码以修复错误。
  • 发现另一个不相关的错误。
  • 将代码更改提交到第一个错误。
  • 停止流程并启动工作项编辑器。
  • 找出 VS2010 糟糕的工作项 UI 并创建一个新的工作项。
  • 找出 VS2010 可怕的错误跟踪器并创建一个新错误。
  • 返回代码。
  • 找出第二个错误在哪里。
  • 修复第二个错误。
  • 返回处理原始错误。

实际上,我的工作流程更像这样:

  • 愉快地编辑代码以修复错误。
  • 发现另一个不相关的错误。
  • 想想自己,“修复那行代码将花费我一个小时来摆弄笨拙的错误跟踪器。去死吧。”。
  • 继续处理原始错误。

总体效果是,我本可以立即修复的错误完全保留在系统中,因为我不会将时间浪费在荒谬的官僚错误报告系统上。什么对您更重要 - 快乐、高效的开发人员,还是从 SVN 中提取的令人印象深刻的报告?

【讨论】:

    【解决方案3】:

    如果你真的想要,你可以看看gurtle, a plugin for tortoise,它允许用户调出错误列表。按照该模板,您可以提供一种快速轻松地创建案例/问题(如果没有案例/问题)的方法。

    除了我不得不说的形式之外,我认为你的目标是错误的并且适得其反。一些善意的流程/政策有时听起来不错,但在实践中最终成为一场噩梦,浪费时间和资源。这是浪费时间和糟糕流程的一个很好的例子。

    【讨论】:

    • 嗨,蒂姆,Gurtle 似乎只适用于谷歌代码问题跟踪器。我在想一些已经写好的东西。不过 Gurtle 代码似乎很容易更改,因此值得考虑。感谢您的提示。
    • 转念一想,这不好,因为它要求所有开发者都安装插件,并且对于非乌龟客户端也不起作用。
    猜你喜欢
    • 1970-01-01
    • 2010-09-07
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-01-02
    • 1970-01-01
    相关资源
    最近更新 更多