Sd - a peer to peer bugtracker I actually like(blog.bestpractical.com)
blog.bestpractical.com
Sd - a peer to peer bugtracker I actually like
http://blog.bestpractical.com/2009/08/prophet-and-sd-07-cavil-are-now-available.html
3 comments
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.
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.
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.
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.
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 ;)
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 ;)
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)
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)
Ditz does this:
http://ditz.rubyforge.org/
http://ditz.rubyforge.org/
ticgit keeps tickets in a git branch of a project. Yeah, it ain't mainstream, but it might become so...
http://wiki.github.com/schacon/ticgit
http://wiki.github.com/schacon/ticgit
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 :)