Hi, On Mon, 28 May 2007, Shawn O. Pearce wrote: > Junio C Hamano <junkio@xxxxxxx> wrote: > > Johan Herland <johan@xxxxxxxxxxx> writes: > > > Ok. But the reverse mapping will help with this, won't it? > > > We'll look up the interesting commits and find their associated > > > note objects directly. > > > > The issue Linus brought up worries me, too. > > > > The "efficient reverse mapping" is still handwaving at this > > stage. What it needs to do is an equivalent to your > > implementation with "refs/notes/<a dir per commit>/<note>". The > > "efficient" one might do a flat file that says "notee note" per > > line sorted by notee, or it might use BDB or sqlite, but the > > amount of the data and complexity of the look-up is really the > > same. A handful notes per each commit in the history (I think > > Linus's "Acked-by after the fact" example a very sensible thing > > to want from this subsystem). > > Please, don't use BDB or sqllite. I really don't trust either. > I've lost data to both. I've *never* lost data to a Git packfile. > ;-) Also, there is the question of dependencies. We don't have to repeat SVN's errors. As for sqllite: the only reason I was _not_ horrified when I realized that cvsserver needs sqllite was that it is not really important for the common user. > I'm actually thinking pack v4. OK, I know its just a virtual hand > waving thing still, but there's really no reason Nico and I cannot > get the damn thing finished before we both wind up buying the farm. Maybe I am missing something important here, but I think we do not at all need a generic database here. Just a key/value store. As it happens, we already have such a beast. It is called object store here. Now, the only reason we cannot do something like "SHA-1 ^ 0xff[...]ff" is the SHA-1 for the note for that commit, is that you could possibly have more than one note for the commit. Of course, without that restriction, we could reuse our object store logic for notes. Side note: the more I think about this notes thing, the more I get disgusted by the deep changes we'd have to do just to accomodate for them. Are they really worth it? Or would something like a pseudo-branch suffice, being one strand of notes (commits), where the second commit parent is actually the commit the note is for? Ciao, Dscho - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
