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? 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? Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in