Re: RFC/Pull Request: Refs db backend

[David Turner <dturner@twopensource.com>]

On Mon, 2015-06-22 at 22:36 -0700, Junio C Hamano wrote:
> David Turner <dturner@twopensource.com> 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.