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 bunch of
On Tue, Jun 23, 2015 at 4:47 AM, Jeff King p...@peff.net 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
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 Wed, Jun 24, 2015 at 1:09 PM, Shawn Pearce spea...@spearce.org 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
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 never
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 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 a
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. You can pack
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 further
On Tue, Jun 23, 2015 at 6:47 PM, Jeff King p...@peff.net 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
On Mon, 2015-06-22 at 22:36 -0700, Junio C Hamano wrote:
David Turner dtur...@twopensource.com 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
[+ronniesahlb...@gmail.com, FYI]
On Mon, Jun 22, 2015 at 5:50 PM, David Turner dtur...@twopensource.com 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
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
On Tue, 2015-06-23 at 17:23 +0700, Duy Nguyen wrote:
On Tue, Jun 23, 2015 at 7:50 AM, David Turner
dtur...@twopensource.com 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
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 have been
-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'
Subject: Re: RFC/Pull Request: Refs db backend
Just to beg
David Turner dtur...@twopensource.com 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
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 is
-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
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 with the
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
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 for
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 gits...@pobox.com 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
David Turner dtur...@twopensource.com 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
25 matches
Mail list logo
