Re: reftable: new ref storage format

From: Shawn Pearce <spearce@spearce.org>
Date: Jul 14, 2017, 15:31 UTC
Message-ID: <CAJo=hJupQAgYsJfeDhtVDtqoA30OpGiuR5o=ZnuRK3CaGo+ZeQ@mail.gmail.com>
In-Reply-To: <CAD0k6qRdq7n=LM7TFJYKvC4uiMMCus8kff-Lm28GiC_G-Feb2Q@mail.gmail.com>

On Fri, Jul 14, 2017 at 7:27 AM, Dave Borowitz <dborowitz@google.com> wrote:

Show 15 quoted lines

> On Thu, Jul 13, 2017 at 8:11 PM, Shawn Pearce <spearce@spearce.org> wrote:
>> In another (Gerrit Code Review), we disable reflogs for
>> the insane refs/changes/ namespace, as nearly every reference is
>> created once, and never modified.
>
> Apologies for the tangent, but this is not true in the most recent
> Gerrit implementation. We update refs/changes/CD/ABCD/1 and
> refs/changes/CD/ABCD/meta in a single BatchRefUpdate, and we set a
> reflog message on the BatchRefUpdate instance, which updates the
> reflog for all refs in the batch. The reflog message on /meta is
> important, and arguably it's useful to be able to correlate that with
> the reflog on /1.
>
> If you think storing reflogs on patch set refs is going to be a
> problem wrt on-disk storage, we should discuss this offline :)

Reflog storage is a problem for Gerrit. It was a problem in early 2009 when servers had a lot less changes. Its going to be even more of a problem now. Sounds like we have to support reflogs in reftable, or something like it.