Re: RFC/Pull Request: Refs db backend

From: Stefan Beller <sbeller@google.com>
Date: Jun 23, 2015, 17:16 UTC
Message-ID: <CAGZ79kap++fZx3X0D95d35XioRURU468xATDZpWHDOAPapAh+Q@mail.gmail.com>
In-Reply-To: <1435020656.28466.8.camel@twopensource.com>

[+<ronniesahlberg@gmail.com>, FYI]

On Mon, Jun 22, 2015 at 5:50 PM, David Turner <dturner@twopensource.com> wrote:

> I've revived and modified Ronnie Sahlberg's work on the refs db
> backend.

Awesome!

Show 6 quoted lines

>
> 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.

Originally I wanted to continue on Ronnies work, but because of the churn in refs I stopped it for a while and took care of other projects (and wanted to come back eventually). Thanks for reviving this topic!

Show 9 quoted lines

> The changes can be found here:
> https://github.com/dturner-tw/git.git on the dturner/pluggable-backends
> branch
>
> The db backend code was added in the penultimate commit; the rest is
> just code rearrangement and minor changes to make alternate backends
> possible.  There ended up being a fair amount of this rearrangement, but
> the end result is that almost the entire git test suite runs under the
> db backend without error (see below for details).

Looking at the end result in refs-be-db.c it feels like there are more functions in the refs_be_db struct, did this originate from other design choices? IIRC Ronnie wanted to have as least functions in there as possible, and share as much of the code between the databases, such that the glue between the db and the refs code is minimal.

Some random comments from looking over the branch briefly:

Typo in commit message "bisect: use refs insfrastructure for BISECT_START"

Some commits contain a ChangeId, which is a Gerrit leftover. :(

Thanks, Stefan

Show 39 quoted lines

>
> 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.  LMDB has a few features that make
> it suitable for usage in git:
>
> 1. It is relatively lightweight; it requires only one header file, and
> the library itself is under 300k (as opposed to 700k for
> e.g. sqlite).
>
> 2. It is well-tested: it's been used in OpenLDAP for years.
>
> 3. It's very fast.  LMDB's benchmarks show that it is among
> the fastest key-value stores.
>
> 4. It has a relatively simple concurrency story; readers don't
> block writers and writers don't block readers.
>
> 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.
>
> To test this backend's correctness, I hacked test-lib.sh and
> test-lib-functions.sh to run all tests under the refs backend. Dozens
> of tests use manual ref/reflog reading/writing, or create submodules
> without passing --refs-backend-type to git init.  If those tests are
> changed to use the update-ref machinery or test-refs-be-db (or, in the
> case of packed-refs, corrupt refs, and dumb fetch tests, are skipped),
> the only remaining failing tests are the git-new-workdir tests and the
> gitweb tests.
>
> Please let me know how it would be best to proceed.
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in