On Tue, Aug 5, 2014 at 2:56 PM, Nico Williams <n...@cryptonector.com> 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 :
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
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.

ronnie sahlberg
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to