至此，我们已经基本完成了版本控制的整个分布式事物。我并不是说一切都很完美，但是从现在开始，这主要只是继续已经开始的事情的问题。
不过，分布式错误跟踪还处于起步阶段，恕我直言。这是相当不方便的，无法在路上使用问题跟踪器，特别是因为我倾向于忘记过去两个小时的更改的目的。是的，我知道，我可以在路上记录日志，并在再次上网时更新传统跟踪器，但仍然......保持我的选择开放等等。 :P
目前，我只知道 Bugs Everywhere 和 Ditz——那些，以及 Fossil。其中，我认为 Fossil 是走得最远的，考虑到它与版本控制方面的集成有多紧密，这并不奇怪。我必须克服重重困难才能让我的合作开发人员考虑 SVN 以外的东西，但是，如果 Fossil 真的就是这样，我不介意再做一次。
不过，在此之前，我想问比我更年长、更明智的头脑：您对这三个人有经验吗？你觉得他们怎么样？你知道其他人吗？请链接到他们，并让我知道他们的表现如何。
We've pretty much licked the whole distributed thing for version control at this point. I'm not saying everything's perfect, but, from hereon out, it's mostly just a matter of continuing what has already been started.
Distributed bug tracking, though, is in its infancy stage, IMHO. It's rather inconvenient, not being able to work with an issue tracker on the road, especially since I have a tendency to forget what my changes over the past two hours were for. Yes, I know, I could just keep a log on the road and update a traditional tracker as soon as I get on the net again, but still... Keeping my options open and all that. :P
Currently, I only know of Bugs Everywhere and Ditz-- those, and the one that comes with Fossil. Of these, I think Fossil is the farthest along, which is not suprising, considering how tightly it's integrated with the version control side of the equation. I've had to jump through quite a few hoops to get my co-devs to even look at something other than SVN, but, if Fossil really is all that, I wouldn't mind doing it again.
Before I do, however, I want to ask older and wiser heads than mine: Do you have experience with these three? What do you think of them? Do you know of others? Please link to them, and let me know how they fared.
发布评论
评论（4）
Eric Sink 在此处对此主题有一些明智的想法 - 他显然对此进行了更多思考我，但他确实提出了一个关键点，那就是在处理功能和错误时与处理开发时有不同的范式，特别是在错误方面。
Eric Sink has some sensible thoughts on the subject here - he's clearly given it more thought than me but he does make one key point which is that you have a different paradigm when dealing with features and bugs to when dealing with development, particularly with respect to bugs.
对于像我这样对这个主题感兴趣，但无法通过 Google 获取足够相关信息的人的附加信息（要么他们不存在，要么我的 Google-fu 严重缺乏）：
bzr log --limit 1显示最后一次提交是从 10 月 9 日上旬开始的。开发速度很慢，但它就在那里。我还没有深入了解be到底提供了什么。文档严重缺乏。该网站上甚至没有快速入门指南。git存储库的克隆对我来说完全失败了。 Google 表示 Ruby 1.9 版本打破了这一点。据说，有 git 克隆可以修复它，但我真的不想弄乱 git。但对我来说仍然不够。必须至少有几个人在一个不平凡的项目中使用过
be或ditz—— 至少，足以能够给出明智的意见。我不关心技术方面——要么该项目在其网站上记录它，要么我可以只查看源代码。我正在寻找的是现实世界的经验：采用它的障碍是什么？某个特定项目缺少什么？考虑到可能需要两年的带薪工作时间，你会补充什么是你真正需要的？诸如此类的事情。
Additional information for people like me who're interested in the subject, but can't pull up enough relevant info through Google (either they're not there, or my Google-fu is severely lacking):
bzr log --limit 1shows the last commit to be from early October 09. The development is slow, but it's there. I haven't yet dived in to see just what exactlybeoffers. Documentation is severely lacking. There isn't even a quick-start guide on the site.gitrepo just utterly fails for me. Google indicates the 1.9 releases of Ruby breaks it. Supposedly, there aregitclones that fix it, but I'd really rather not mess withgit.Still not enough for me, though. There has to be at least a couple of people who've used either
beorditzfor a non-trivial project-- at least, enough to be able to give an informed opinion.I don't care about the technical side-- either the project documents it on its Web site, or I could just look at the source. What I'm looking for is real-world experience: What were the hurdles to its adoption? What is a particular project lacking? What would you add, that you really need, given maybe two years of paid time to work on it? Stuff like that.
Fossil 作为“易于设置”的分布式错误跟踪器 ，并且有一个很好的自动同步工具，可以让开发人员在无需干预的情况下分享他们的错误。
首先，
您的开发人员也做同样的事情
除此之外，仅此而已。
编辑 - 看看 也可以自定义票务系统。
Fossil works as an 'easy to setup' Distributed Bug tracker , and has a nice autosync facility that lets developers share their bugs without intervention.
to get started,
your developers do the same
There is not much more to it than that.
Edit - take a look at Customizing The Ticket System too.
因为我想要（嗯，需要，真的）一个可能（也许，希望）现在工作的解决方案，我们采用了以下设置：
它可能不是完美的设置，甚至也不是对于某些人来说特别可以接受，但它符合现在的工作标准。我还是想向别人学习更多；也许我错过了其他解决方案的一个不太明显的特征，这会导致我变得足够狂热，以至于我会打扰我的共同开发人员切换。
无论如何，如果有人使用这个或类似的工具集，请告诉我到目前为止它对您来说效果如何，您的情况如何等等。现在，我们的这个解决方案已经三天了，所以到目前为止我确实没有太多数据可以分享。
Because I wanted (well, needed, really) a solution that could probably (maybe, hopefully) work right now, we went with the following setup:
It may not be the perfect setup, nor even a particularly acceptable one to some, but it meets the criteria of working right now. I still would like to learn more from others; maybe I'm missing a not-so obvious trait of other solutions that would cause me to become fanatic enough that I'd bug my co-devs to switch.
Anyway, if anyone uses this, or a similar, set of tools, please let me know how it's worked out so far for you, what your circumstances are, etc. Right now, this solution of ours is all of three days old, so I really don't have much data to share as of yet.