On Mon, 2015-06-22 at 22:36 -0700, Junio C Hamano wrote: > David Turner <dturner@xxxxxxxxxxxxxxxx> writes: > > > I've revived and modified Ronnie Sahlberg's work on the refs db > > backend. > > > > The work is on top of be3c13e5564, Junio's "First batch for 2.5 cycle". > > I recognize that there have been changes to the refs code since then, > > and that there are some further changes in-flight from e.g. Michael > > Haggerty. If there is interest in this, I can rebase once Michael's > > changes land. > > ... > > The db backend runs git for-each-ref about 30% faster than the files > > backend with fully-packed refs on a repo with ~120k refs. It's also > > about 4x faster than using fully-unpacked refs. In addition, and > > perhaps more importantly, it avoids case-conflict issues on OS X. > > > > I chose to use LMDB for the database... > > ... > > Ronnie Sahlberg's original version of this patchset used tdb. The > > advantage of tdb is that it's smaller (~125k). The disadvantages are > > that tdb is hard to build on OS X. It's also not in homebrew. So lmdb > > seemed simpler. > > "If there is interest"? Shut up and take my money ;-) > > More seriously, that's great that you stepped up to resurrect this > topic. In a sense, the choice of sample database backend does not > matter. I do not care if it is tdb, lmdb, or even Berkeley DB as > long as it functions. ;-) > > As long as the interface between ref-transaction system on the Git > side and the database backend is designed right, your lmdb thing can > serve as a reference implementation for other people to plug other > database backends to the same interface, right? Yes. > As one step to > validate the interface to the database backends, it would be nice to > eventually have at least two backends that talk to meaningfully > different systems, but we have to start somewhere, and "for now we > have lmdb" is as good a place to start as any other db backend. > > I wonder if we can do a "filesystem" backend on top of the same > backend interface---is that too much impedance mismatch to make it > unpractical? The patch series does include a filesystem backend, which is simply the current ref infrastructure with extremely minor changes. -- 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