在这一点上，我们几乎已经完成了整个分布式的版本控制。我并不是说一切都是完美的，但是，从现在开始，这主要只是继续已经开始的事情。
但是，分布式错误跟踪还处于起步阶段，恕我直言。这很不方便，不能在路上使用问题跟踪器，特别是因为我倾向于忘记过去两个小时的更改是为了什么。是的，我知道，只要我再次上网，我就可以在路上记录并更新传统的追踪器，但仍然......保持我的选择开放等等。:P
目前，我只知道Bugs Everywhere和Ditz——那些，以及Fossil附带的那个。其中，我认为 Fossil 走得最远，考虑到它与版本控制方面的紧密集成程度，这并不令人惊讶。为了让我的共同开发人员甚至可以查看除 SVN 之外的其他东西，我不得不跳了很多圈，但是，如果 Fossil 真的就是这样，我不介意再做一次。
然而，在我这样做之前，我想问一下比我年长和聪明的头脑：你有这三个方面的经验吗？你觉得他们怎么样？你知道别人吗？请链接到他们，让我知道他们的表现。
Fossil作为一个“易于设置”的分布式错误跟踪器工作，并且有一个很好的自动同步工具，可以让开发人员在没有干预的情况下分享他们的错误。
开始，
您的开发人员也会这样做
没有比这更多的了。
编辑 - 也看看定制票务系统。
因为我想要（嗯，确实需要）一个可能（也许，希望）现在可以工作的解决方案，所以我们采用了以下设置：
它可能不是完美的设置，甚至对某些人来说也不是特别可接受的设置，但它符合现在工作的标准。我仍然想向别人学习更多；也许我错过了其他解决方案的一个不那么明显的特征，这会导致我变得足够狂热，以至于我会让我的共同开发者切换。
无论如何，如果有人使用这个或类似的工具集，请告诉我到目前为止它是如何为你解决的，你的情况如何，等等。现在，我们的这个解决方案已经三天了，所以到目前为止，我真的没有太多数据可以分享。
Eric Sink 在这里对这个主题有一些明智的想法——他显然比我考虑得更多，但他确实提出了一个关键点，那就是你在处理特性和错误时有一个不同的范式，在处理开发时，特别是关于错误。
对于像我这样对该主题感兴趣但无法通过 Google 获取足够相关信息的人的其他信息（他们不在那里，或者我的 Google-fu 严重缺乏）：
bzr log --limit 1显示最后一次提交是从 10 月 9 日上旬开始的。开发速度很慢，但它就在那里。我还没有深入了解究竟be提供了什么。文档严重缺乏。该网站上甚至没有快速入门指南。git回购的克隆对我来说完全失败了。Google 指出 Ruby 的 1.9 版本打破了它。据说，有git修复它的克隆，但我真的不想弄乱git.不过，对我来说仍然不够。必须至少有几个人使用过be或ditz用于不平凡的项目——至少，足以提供明智的意见。
我不关心技术方面——要么是项目在其网站上记录它，要么我可以只看源代码。我正在寻找的是真实世界的经验：采用它的障碍是什么？一个特定的项目缺少什么？考虑到可能有两年的带薪工作时间，你会补充什么，你真正需要的？像这样的东西。