>  On Thu, Mar 6, 2008 at 9:44 AM, aslak hellesoy <aslak.helle...@gmail.com> wrote:

>  >  With that done it was time to tackle the next challenge. History. I
>  >  needed to keep track of where each card had been at what time in order
>  >  to derive these wonderful burndowns and other metrics. Long story
>  >  short, I've rewritten this 4-5 times, using acts-as-versioned,
>  >  acts-as-versioned-with-relations (or something), subversion (I think
>  >  you saw that Johan) and a File DB. I have failed every time.

>  >  Storing stories and tasks in Subversion actually came closest, I had
>  >  mostly technical problems here. I haven't done much about this in a
>  >  while. ThoughtWorks has released Mingle, which is really cool, but it
>  >  doesn't tie in with your SCM as Johan describes.

>  >  I definitely think the SCM is the way to go. That's where bugs, RFEs,
>  >  stories, tasks etc should live. I think a Wiki-style format with some
>  >  structure is the way to go here.

>  I'm not so sure it really needs to actually _be_ in the SCM anymore.
>  As long as I could edit it with my $EDITOR I think I'll be happy.

>  I began on a prototype implementation yesterday using Yurii's StrokeDB
>  (http://gitorious.org/projects/strokedb). The reason I went for that
>  rather than directly in git, is so that I can dictate the structure a
>  bit more and gear it towards tickets, instead of just content in
>  general. It'll also mean we can potentially implement our own merge
>  strategies. It's also in pure ruby (at least for now)  and I know
>  Yurii's goals for it fits in pefectly with ours. And unlike CouchDB,
>  it's easily embedable, meaning a console interface, web interface and
>  a rubycocoa interface is very feasible without requiring special
>  daemons to be running.

>  So basically, the  goal of the prototype is to implement a generic
>  structure for tickets and whatever data thats associated with them,
>  along with a commandline interface. And hopefully also
>  syncing/replication between ticket databases.

>  So the idea is to have it in the git repository dir, but .gitignore'd
>  and controlled with a separate binary, autoclosing/commenting in
>  commit messages would be done via a git hook. And by having the
>  "ticket database" in the git dir allows us to query the git-repository
>  from the ticket system, rather than the other way around.

>  >  I would try to keep it decoupled (but interoperable) from Gitorius if
>  >  possible. And possibly from Git too. An SCM based issue tracker is a
>  >  novel idea, and if we can make something that would work in many SCMs
>  >  it could potentially attract a lot of contributors and become a really
>  >  nice product.

>  It would be fairly decoupled by default, since it wouldn't base its
>  storage mechanism on any SCM features. However, my biggest concern is
>  that this distributed ticketing system would end up being too exotic
>  for most people, but then again, so where things like Git for most
>  people not long ago (though I'd argue it still is for the masses ;)).
>  But I think a good webinterface that acts almost like they're used to
>  in other systems will go a long way, along with a powerful
>  distribution model for those who want/need it.

>  And I've looked at DITrack, DisTract and BugsEveryone, but the most
>  common problem is that they're either too closely tied with a SCM I
>  don't use, or the fail to give me the overview a bugtracker should be
>  able to give me. But most importantly, I'm interested in exploring
>  this topic fully myself (and anyone wanting to join in), and with
>  gitorious.org in mind.

>  >  I am definitely interested in contributing to this.

>  Still interested? ;)

>  >  Aslak

>  Cheers,
>  JS