Re: Pluggable backends for refs,wip

On Tue, Aug 5, 2014 at 2:56 PM, Nico Williams [off-list ref] wrote:

Personally (a user of, not a maintainer of, git) I really want some
alternative backends.  In particular I'm after something like Fossil's
use of SQLite3; I want a SQLite3 backend for several reasons, not the
least of which is the power of SQL for looking at history.

I'm not sure that I necessarily want a daemon/background process.  I
get the appeal (add inotify and bingo, very fast git status, always),
but it seems likely to add obnoxious failure modes.

As to a SQLite3-type backend, I am of two minds: either add it as a
bolt-on to the builtin backend, or add it as a first-class backend
that replaces the builtin one.  The former is nice because the SQLite3
DB becomes more of a cache/index and query engine than a store, and
can be used without migrating any repos, but the latter is also nice
because SQLite3 provides strong ACID transactional semantics on local
filesystems.

This will allow you to do either or both, depending on what you want.

I am adding one new first-class backend to talk to a separate daemon :
  refs-be-db.c
which then talks to a separate daemon   refsd-tdb.c

refsd-tdb.c is 7 RPCs and ~500 lines of code for a naive
implementation for a standalone separate daemon implementation.


If you rather want want a new first-class backend builtin to git
itself instead of as a separate daemon, then that will be possible
too.
It just means that you will have to base the work on refs-be-db.c
which is a much larger and complex code base than refsd-tdb.c.

But yeah, once this work is finished, you will be able to build new
first-class ref backends if you so wish.
Please see refs-be-db.c  that is the file and the methods you will
need to implement in order to have a first-class SQL* backend.


regards
ronnie sahlberg