Re: [RFC] git integrated bugtracking

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jun 10, 2007, 07:44 UTC
Message-ID: <Pine.LNX.4.64.0706100831310.4059@racer.site>
In-Reply-To: <Pine.LNX.4.64.0706092152180.5848@iabervon.org>

Hi,

On Sat, 9 Jun 2007, Daniel Barkalow wrote:

> 1) It's probably best to use some new types, rather than trees and 
> commits. This gives you more flexibility to structure things in ways 
> that exactly fit what's going on, which is one of the main reasons git 
> is so good for version control.

I fail to see why this has to be a new type. The flexibility in Git lies IMHO therein that it does _not_ have a plethora of objects. Rather, there are just 4 object types, which serve their purpose well, indeed. (I would even have argued that tag objects could have been simple commit objects, with an additional header "tag", but oh well.)

I suspect that you want to introduce a different object type to be able to implement a new algorithm. But I think that the appropriate data structure is still contained in the existing set of types in Git.

> 2) It's probably best to have the history be per-bug, with each revision 
> being an update to that report, and have the complete database be a 
> refs/ subdirectory.

I don't think that this is a good solution:

>From the implementation view point, a lot of branches sucks

performance-wise. Especially since we do not pack branch refs.

Side note: I recently kicked around the idea to actually keep the refs in the packed-refs file, and for updating refs do a lock-mmap-findref-replace-or-rewrite, where a rewrite only happens if we delete or insert a ref.

Then, we could even unify the info/refs and packed-refs, so that we don't hear bugreports about http transport not working every week or so.

Just an idea.

Ciao, Dscho