On Wed, Jun 24, 2015 at 05:49:20AM -0400, Jeff King wrote:
> I don't know how much that helps for the JGit situation. It punts the
> native code out of JGit, but people using JGit still have to have the
> native helper from git on their system. I have no problems at all with
> pluggable $FANCY_DB
On Wed, 2015-06-24 at 05:14 -0400, Jeff King wrote:
> On Tue, Jun 23, 2015 at 02:18:36PM -0400, David Turner wrote:
>
> > > Can you describe a bit more about the reflog handling?
> > >
> > > One of the problems we've had with large-ref repos is that the reflog
> > > storage is quite inefficient.
On Tue, 2015-06-23 at 23:27 +0200, Michael Haggerty wrote:
> On 06/23/2015 09:53 PM, David Turner wrote:
> > On Tue, 2015-06-23 at 17:51 +0200, Michael Haggerty wrote:
> > [...]
> >> * I don't like the fact that you have replaced `struct ref_transaction
> >> *` with `void *` in the public interface
On Wed, Jun 24, 2015 at 1:09 PM, Shawn Pearce wrote:
>>> I chose to use LMDB for the database. LMDB has a few features that make
>>> it suitable for usage in git:
>>
>> One of the complaints that Shawn had about sqlite is that there is no
>> native Java implementation, which makes it hard for JGi
On Tue, Jun 23, 2015 at 11:09:40PM -0700, Shawn Pearce wrote:
> Yes. $DAY_JOB's DFS implementation never expires reflogs, allowing it
> to be used as a history to inspect what happened. Its been useful a
> couple of times to investigate and recover from a few accidental
> deletions.
>
> Once you
On Tue, Jun 23, 2015 at 02:18:36PM -0400, David Turner wrote:
> > Can you describe a bit more about the reflog handling?
> >
> > One of the problems we've had with large-ref repos is that the reflog
> > storage is quite inefficient. You can pack all the refs, but you may
> > still be stuck with a
On Tue, Jun 23, 2015 at 08:10:03PM +0700, Duy Nguyen wrote:
> > - we keep a key/value index mapping the name of any branch that exists
> > to the byte offset of its entry in the logfile. This would probably
>
> One key/value mapping per branch, pointing to the latest reflog entry,
> or one
On Tue, Jun 23, 2015 at 4:47 AM, Jeff King wrote:
>
> One of the problems we've had with large-ref repos is that the reflog
> storage is quite inefficient.
Yup. We ran into this with Gerrit Code Review years ago. The
refs/changes/... namespace created by Gerrit Code Review is 1 ref per
snapshot p
David Turner writes:
> On Tue, 2015-06-23 at 15:53 -0400, David Turner wrote:
>> > * Regarding MERGE_HEAD: you take the point of view that it must continue
>> > to be stored as a file. And yet it must also behave somewhat like a
>> > reference; for example, `git rev-parse MERGE_HEAD` works today.
On Tue, 2015-06-23 at 15:53 -0400, David Turner wrote:
> > * Regarding MERGE_HEAD: you take the point of view that it must continue
> > to be stored as a file. And yet it must also behave somewhat like a
> > reference; for example, `git rev-parse MERGE_HEAD` works today.
> > MERGE_HEAD is also used
On 06/23/2015 09:53 PM, David Turner wrote:
> On Tue, 2015-06-23 at 17:51 +0200, Michael Haggerty wrote:
> [...]
>> * I don't like the fact that you have replaced `struct ref_transaction
>> *` with `void *` in the public interface. On a practical level, I like
>> the bit of type-safety that comes w
> -Original Message-
> From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On
> Behalf Of David Turner
> Sent: June 23, 2015 4:22 PM
> To: Randall S. Becker
> Cc: 'Stefan Beller'; 'git mailing list'; 'ronnie sahlberg'
> Just to beg a request: LMDB is not available on some MPP architectures to
> which git has been ported. If it comes up, I beg you not to add this as a
> dependency to base git components.
My changes make `configure` check for the presence of liblmdb. The LMDB
code is only built if liblmdb is pr
> -Original Message-
> From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On
> Behalf Of David Turner
> Sent: June 23, 2015 4:05 PM
> To: Stefan Beller
> Cc: git mailing list; ronnie sahlberg
> Subject: Re: RFC/Pull Request: Refs db backend
>
>
On Tue, 2015-06-23 at 10:16 -0700, Stefan Beller wrote:
> > 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
On Tue, 2015-06-23 at 17:51 +0200, Michael Haggerty wrote:
> On 06/23/2015 02:50 AM, David Turner wrote:
> > I've revived and modified Ronnie Sahlberg's work on the refs db
> > backend.
> >
> > The work is on top of be3c13e5564, Junio's "First batch for 2.5 cycle".
> > I recognize that there hav
On Tue, 2015-06-23 at 17:23 +0700, Duy Nguyen wrote:
> On Tue, Jun 23, 2015 at 7:50 AM, David Turner
wrote:
> > To test this backend's correctness, I hacked test-lib.sh and
> > test-lib-functions.sh to run all tests under the refs backend.
>
> Now we have two. split-index also benefits from runni
On Tue, 2015-06-23 at 07:47 -0400, Jeff King wrote:
> On Mon, Jun 22, 2015 at 08:50:56PM -0400, David Turner wrote:
>
> > 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 ful
On Mon, 2015-06-22 at 22:36 -0700, Junio C Hamano wrote:
> David Turner writes:
>
> > I've revived and modified Ronnie Sahlberg's work on the refs db
> > backend.
> >
> > The work is on top of be3c13e5564, Junio's "First batch for 2.5 cycle".
> > I recognize that there have been changes to the
[+, FYI]
On Mon, Jun 22, 2015 at 5:50 PM, David Turner wrote:
> I've revived and modified Ronnie Sahlberg's work on the refs db
> backend.
Awesome!
>
> 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,
On 06/23/2015 02:50 AM, David Turner wrote:
> I've revived and modified Ronnie Sahlberg's work on the refs db
> backend.
>
> 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 f
On Tue, Jun 23, 2015 at 6:47 PM, Jeff King wrote:
> I was thinking of actually moving to a log-structured ref storage.
> Something like:
>
> - any ref write puts a line at the end of a single logfile that
> contains the ref name, along with the normal reflog data
>
> - the logfile is the s
On Mon, Jun 22, 2015 at 08:50:56PM -0400, David Turner wrote:
> 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
On Tue, Jun 23, 2015 at 12:36 PM, Junio C Hamano wrote:
> "If there is interest"? Shut up and take my money ;-)
Yeah. This may be the next big thing since pack bitmap. It's even
better if it enters 'master' hand in hand with pack protocol v2, but I
think v2 needs more time.
On Tue, Jun 23, 2015
David Turner writes:
> I've revived and modified Ronnie Sahlberg's work on the refs db
> backend.
>
> 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-flig
25 matches
Mail list logo
