

Sd - a peer to peer bugtracker I actually like - mst
http://blog.bestpractical.com/2009/08/prophet-and-sd-07-cavil-are-now-available.html

======
mst
I've been using this for crosstalk with rt and trac installs for some time -
being something of a command line addict I find that the simple but relatively
sane UI provided is not only rather good but very easy to shell script around
for custom stuff.

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 :)

------
drewr
I'm intrigued by Prophet. Anybody here using it?

 _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._

~~~
gcv
I'm interested, too. Reading the documentation now
(<http://search.cpan.org/dist/Prophet/lib/Prophet/Manual.pod>). I must say,
the linked presentation on how Prophet came about is hilarious
(<http://www.slideshare.net/obrajesse/web-20-is-sharecropping>), full of
vintage screenshots.

------
ghempton
Bugs are so tightly coupled to the actual code that I am surprised no
mainstream bug trackers (that I know of) actually store their databases in the
version control itself. Seems like it would be easy to just store and read
from the git repository, in which case all the p2p functionality is free.

~~~
obra
Your insight is a reasonable one -- and it's where we started when we were
designing SD. It quickly became apparent to us that there's a subtle but
serious impedance mismatch.

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 ;)

~~~
tetha
I have found similar insights to you.

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)

