分布式错误跟踪器与DVC一起使用

Question

此时我们已经完全舔了整个分布式的版本控制。我并不是说一切都很完美，但是，从这里开始，这主要只是继续已经开始的事情。

分布式错误跟踪虽然处于起步阶段，恕我直言。这是相当不方便的，无法在路上与问题跟踪器一起工作，特别是因为我倾向于忘记过去两小时内我的变化是什么。是的，我知道，我可以在路上记录并更新一个传统的跟踪器，一旦我再次上网，但仍然......保持我的选择开放和所有这一切。 ：P

目前，我只知道Bugs Everywhere和Ditz - 那些，以及Fossil附带的那些。其中，我认为Fossil是最远的，考虑到它与版本控制方面的集成程度有多紧密，这并不令人惊讶。我不得不跳过相当多的箍来让我的共同开发者甚至看看除了SVN之外的其他东西，但是，如果Fossil真的就是那样，我不介意再做一次。

然而，在我这样做之前，我想问的是比我年长更聪明的人：你有这三个经验吗？你觉得他们怎么样？你认识其他人吗？请链接到他们，让我知道他们的表现。

Answer 1

Fossil可以作为“易于设置”Distributed Bug tracker，并且具有良好的自动同步功能，可让开发人员无需干预即可共享其错误。

开始使用，

1. 下载您选择的化石二元组
2. fossil new bugs.fossil
3. fossil ui bugs.fossil（运行服务器）

你的开发人员做同样的事情

1. 下载您选择的化石二元组
2. 化石克隆
3. fossil ui bugs.fossil
4. 将“cron”作业设置为“化石同步...”，以便将错误传播给所有用户fossil self-hosting repositories demonstrate

没有比这更多的东西了。

编辑 - 也请查看Customizing The Ticket System。

Answer 2

因为我想（好吧，需要，真的）一个可能（可能，希望）正常工作的解决方案现在，我们采用了以下设置：

• Bazaar-NG作为VCS
• Bugs Everywhere作为错误跟踪器
• Zim as wiki

它可能不是完美的设置，甚至也不是特别可接受的设置，但它符合现在的标准。我还是想从别人那里学到更多东西;也许我错过了一个不那么明显的其他解决方案的特征，这些特征会让我变得狂热，以至于我会让我的共同开发人员失误。

无论如何，如果有人使用这个或类似的工具集，请让我知道它到目前为止是如何制定的，你的具体情况等等。现在，我们的解决方案是三天旧的，所以我真的没有太多的数据要分享。

Answer 3

Eric Sink对这个问题有一些明智的想法here - 他显然比我更多地考虑了它，但他确实提出了一个关键点，那就是你在处理交易中的特征和错误时有不同的范例随着发展，特别是在虫子方面。

Answer 4

像我这样对这个主题感兴趣的人的其他信息，但无法通过谷歌提供足够的相关信息（他们不在那里，或者我的Google-fu严重缺乏）：

• 再次分支Bugs Everywhere。 bzr log --limit 1显示最后一次提交是从09年10月初开始的。开发速度很慢，但它就在那里。我还没有潜入，看看be提供了什么。文档严重缺乏。网站上甚至没有快速入门指南。
• Ditz，使用其主线git repo的克隆对我来说完全失败了。 Google表示Ruby的1.9版本打破了它。据说，有git克隆可以修复它，但我真的不想搞砸git。
• Fossil在SO上至少有一个相关问题：What do people think of the fossil DVCS?（它甚至得到了作者的回答！）。非常尊重D. Richard Hipp（SQLite和Fossil的作者，以及我只能在维基百科上使用和阅读的其他非常酷的东西），但我也希望得到其他凡人的反馈。

但对我来说还不够。必须有至少几个人使用be或ditz进行非平凡的项目 - 至少足以让他们能够给予知情的意见。

我不关心技术方面 - 要么项目在网站上记录，要么我只能查看来源。我正在寻找的是现实世界的经验：采用它的障碍是什么？什么是特定项目缺乏？你有什么需要补充的，你真正需要的，可能有两年的付出时间来处理它？这样的东西。