Sd - a peer to peer bugtracker I actually like
blog.bestpractical.com
blog.bestpractical.com
Plus the "wget <url> | perl" installation is so wonderfully trivial it makes me incredibly happy (and I have some truly weird and hacked up perl installs on certain dev boxes and none of them have managed to fsck up the installer yet :)
Prophet is a lightweight schemaless database designed for peer to peer replication and disconnected operation. Prophet keeps a full copy of your data and (history) on your laptop, desktop or server. Prophet syncs when you want it to, so you can use Prophet-backed applications whether or not you have network.
It turns out that the way you want to handle merging of databases is different than how you want to handle merging of codebases.
On top of that, the obvious advantage of storing your bugs in your VCS is "branching bugs" -- unfortunately, that turns out to hurt really badly once you want to start asking questions about "what bugs are open?" and "has bug xyz been fixed."
Besides, we have a bunch of other p2p database apps we want to build that aren't sourcecode related ;)
The first problem I had with using ditz on git was that I suddenly need git and ditz to just say 'hey, I'll implement this feature'. If I use trac, I just need a browser (which is clearly an advantage if you have conservative computer-pool administrators at the university :) ).
Second, I don't like how git+ditz allows one to easily see OLD version data. If you forget to pull before checking your ditz, you see old data, so you don't see how I started working on the task you start working on, so we both do the same thing. That won't happen that easily if your task&bug-management lies on a webserver.
This, merging and branching becomes a lot more bothersome, at least if the issue-tracker is not implemented carefully, as you said.
Third, I kept running into problems, because I liked to work on certain tasks in parallel, on differnt branches (because both were interesting :) ), this did not work out well with ditz either, because comments to these tasks ended up being on different branches and this, not in a central thingie.
Thus, I'd conclude that there is a certain analogy going on here: Programmers need non-programmer managers to reach peak efficiency (even though a programmer-compatible and understanding manager makes this even better), and a repository needs a good issue management tool to reach peak efficiency (even though a repository-compatible issue management tool makes this even better)