Re: [RFC] git integrated bugtracking

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

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