git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: David Kastrup <dak@gnu.org>
To: Jeff King <peff@peff.net>
Cc: Shawn Pearce <spearce@spearce.org>,
	Michael Haggerty <mhagger@alum.mit.edu>,
	git discussion list <git@vger.kernel.org>,
	Vicent Marti <tanoku@gmail.com>,
	Brad King <brad.king@kitware.com>,
	Johan Herland <johan@herland.net>
Subject: Re: [RFC/WIP] Pluggable reference backends
Date: Mon, 10 Mar 2014 17:14:02 +0100	[thread overview]
Message-ID: <87k3c2820l.fsf@fencepost.gnu.org> (raw)
In-Reply-To: <20140310155230.GA29801@sigill.intra.peff.net> (Jeff King's message of "Mon, 10 Mar 2014 11:52:30 -0400")

Jeff King <peff@peff.net> writes:

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

Of course, the basic premise for this feature is "let's assume that our
file and/or operating system suck at providing file system functionality
at file name granularity".  There have been two historically approaches
to that problem that are not independent: a) use Linux b) kick Linus.

Option b) has been fairly successful over quite a bit of time, but at
the current point of time, it has become harder to aim that kick on a
single person and/or where it counts.

The database approach is an alternative approach based on kicking an
alternate set of people, namely database rather than operating system
providers, based on the assumption that the former have softer behinds
(the backend-based approach) making them more sensitive to kicking.

So the database approach is most promising on the "what are we going to
do if our operating system vendor won't bother with sensible file system
performance" angle.  Which isn't doing total system architecture a
favor.

Personally, I have little sympathy for helping subpar systems, keeping
them on life support while they are in turn trying to squish the better
systems.

But then it is not me doing the actual work, so this is no more than an
idle reflection.

-- 
David Kastrup

  reply	other threads:[~2014-03-10 16:14 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-10 11:00 [RFC/WIP] Pluggable reference backends Michael Haggerty
2014-03-10 11:44 ` Johan Herland
2014-03-10 14:30 ` Shawn Pearce
2014-03-10 15:51   ` Max Horn
2014-03-10 15:52   ` Jeff King
2014-03-10 16:14     ` David Kastrup [this message]
2014-03-10 16:28       ` David Lang
2014-03-10 19:42       ` Jeff King
2014-03-10 19:56         ` David Kastrup
2014-03-10 17:46     ` Junio C Hamano
2014-03-10 17:56       ` Jeff King
2014-03-10 21:07     ` Michael Haggerty
2014-03-11  2:39       ` Shawn Pearce
2014-03-12 10:26         ` egit vs. git behaviour (was: [RFC/WIP] Pluggable reference backends) Andreas Krey
2014-03-12 16:48           ` Shawn Pearce
2014-03-11 10:56 ` [RFC/WIP] Pluggable reference backends Karsten Blees
2014-03-12 11:43   ` Michael Haggerty

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87k3c2820l.fsf@fencepost.gnu.org \
    --to=dak@gnu.org \
    --cc=brad.king@kitware.com \
    --cc=git@vger.kernel.org \
    --cc=johan@herland.net \
    --cc=mhagger@alum.mit.edu \
    --cc=peff@peff.net \
    --cc=spearce@spearce.org \
    --cc=tanoku@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).