Re: [RFC/WIP] Pluggable reference backends

From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Mar 10, 2014, 21:07 UTC
Message-ID: <531E2986.8050604@alum.mit.edu>
In-Reply-To: <20140310155230.GA29801@sigill.intra.peff.net>

On 03/10/2014 04:52 PM, Jeff King wrote:

Show 16 quoted lines

> On Mon, Mar 10, 2014 at 07:30:45AM -0700, Shawn Pearce wrote:
> 
>>> * Store references in a SQLite database, to get correct transaction
>>>   handling.
>>
>> No to SQLLite in git-core. Using it from JGit requires building
>> SQLLite and a JNI wrapper, which makes JGit significantly less
>> portable. I know SQLLite is pretty amazing, but implementing
>> compatibility with it from JGit will be a big nightmare for us.
> 
> That seems like a poor reason not to implement a pluggable feature for
> git-core. If we implement it, then a site using only git-core can take
> advantage of it. Sites with JGit cannot, and would use a different
> pluggable storage mechanism that's supported by both. But if we don't
> implement, it hurts people using only git-core, and it does not help
> sites using JGit at all.

I think it's important to distinguish between two types of backend:

* Exotic backends, optimized for servers, or embedded systems, or other
controlled environments where the person deploying Git can decide about
the whole technology stack.  Here I say let a thousand flowers bloom.
If user A wants to try an Oracle backend and only uses JGit, there's no
need for him to implement the equivalent backend for git-core or libgit2.

* Mainstream backends, intended for use by end-users on their
workstations and notebooks.  Such backends will be pretty worthless if
they are not supported more or less universally, because one user will
want to use the command line and Eclipse, another Visual Studio and
TortoiseGit, a third will use GitHub for Mac plus a bunch of shell
scripts written by his IT department.  A backend that is not supported
by the big three Git implementations (git-core, libgit2, and JGit) will
probably be rejected by users.  Realistically there will be at most a
couple of mainstream backends--in fact probably usually a single
established one and occasionally a single next-generation one waiting
for people to migrate slowly to it.  For mainstream backends I think it
is important for the implementations to plan and coordinate ahead of
time to make sure everybody's concerns are addressed.

It sounds to me like Shawn is saying "please don't make a SQLite-based backend the new default git-core backend" and Peff is saying "there is no reason that a Git hosting service shouldn't experiment with a SQLite-based backend". I see no contradiction there [1].

Also, please remember that I'm not advocating a SQLite backend or any other at this time. I'm only refactoring code to open the way for *future* flamefests :-)

Michael

[1] There might of course be a technical argument about whether a SQLite-based backend would be SO AWESOME for end-users that switching to it would be worth the extra inconvenience for the JGit folks. Personally I'm skeptical.

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/