From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,AWL,BAYES_00, URIBL_RED shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id B6E851F5AE; Mon, 26 Apr 2021 20:34:28 +0000 (UTC) Date: Mon, 26 Apr 2021 20:34:28 +0000 From: Eric Wong To: meta@public-inbox.org Subject: Re: lei-managed pseudo mailing lists Message-ID: <20210426203428.GA5692@dcvr> References: <20210426164454.5zd5kgugfhfwfkpo@nitro.local> <20210426173726.GA22986@dcvr> <20210426182020.olonbxkc6a2gfzl3@nitro.local> <20210426184717.GA29112@dcvr> <20210426194659.d5w2nkeqvtyni4ay@nitro.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20210426194659.d5w2nkeqvtyni4ay@nitro.local> List-Id: Konstantin Ryabitsev wrote: > I'm just worried that if we overuse the alternates, then we may find ourselves > in a situation where when we repack the "every blob" shared repository, we'll > end up with a pack that isn't really optimized to be used by any of the > member repos. So, in a situation where a clone is performed, git-upload-pack > will have to spend a lot of cycles navigating through the monstrous parent > pack just to build and re-compress the small subset of objects it needs to > send. > > Git has ways of dealing with this by allowing to set things like pack islands, > but it's finicky and requires that each child repo is defined as refs in the > parent repo. We deal with this in grokmirror, but it's messy and requires > properly tracking child repo additions/removals/etc. At least for personal use, I've been meaning to look into automatically managing islands. > I think it may be one of those cases where wasting disk space on duplicate > objects is worth the CPU cycle savings. Agreed for serving public inboxes. > On Mon, Apr 26, 2021 at 06:47:17PM +0000, Eric Wong wrote: > > The aforementioned maxuid prevents stuff that's too old from > > being seen. Otherwise, there's always "public-inbox-learn rm". > > How would it handle the situation where we import a new list into lore with a > 10-year-long archive of messages? maxuid is either per-inbox or per-extindex. If the search is going off of inboxes via --only, then it would not see the new inbox at all. If it's on an extindex like "all", then yes, the newly-imported historical messages would show up. So using "rt:" (Received time) is helpful in the [extindex "all"] case Also, the approxidate parsing is done every time with "lei up", so you can have a rolling window with "rt:last.week.." as a search parameter.