Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Subject: Re: Proposal: new fsfs.conf properties
References: <727D8E16AE957149B447FE368139F2B5A9023540@SERVER10>
 <8ea18364-3d34-4d99-2d5e-e4169ee31542@apache.org>
 <20170711205035.GG58742@jessup.stsp.name>
 <9c674b4e-8529-c34e-a351-824dc60c894c@apache.org>
 <CAB84uBW0F_Ofw5J+kzOMyQe=7jg_qkRNjCZN6t7qEePgLb9uHA@mail.gmail.com>
 <625629b6-5d99-6e3d-8367-e230d02edc34@apache.org>
 <CAB84uBWAnnSRUfc1kC175x2seTV_7_Gy6snRaoWQKagjn-rKDA@mail.gmail.com>
 <CA+298UjfMrvG0d_0_j1e5uwOyjiaQeZzPpLMxGpB+Z3NJXNo3A@mail.gmail.com>
 <0fc29069-061f-86e4-06f3-f937a1152aab@apache.org>
 <CA+298Uh90oRW4V0-EOiRpXLuGSpgmhPgex+dzqZ1mHxi3D0X7g@mail.gmail.com>
 <20170713140703.s3hyttnyxm5k4ipi@tarpaulin.shahaf.local2>
 <b7cdf4f1-873e-d971-4417-63fb47d6b6aa@apache.org>
 <CA+298UgizDF2j5-D13HzrdhGtA+-t7CT_x3FngYSDkPDVN2YzA@mail.gmail.com>
 <26478b63-e2cd-7d09-adaa-409b4933f8df@apache.org>
 <CA+298Ui2=ZuzZb=4n2CZyJG2zRSr4wCe=Zdx9hAX5JpidskfSQ@mail.gmail.com>
To: Subversion Development <dev@subversion.apache.org>
From: =?UTF-8?Q?Branko_=c4=8cibej?= <brane@apache.org>
Organization: The Apache Software Foundation
Message-ID: <91ac3363-13f4-06dd-2834-b3ff1ce0df77@apache.org>
Date: Thu, 13 Jul 2017 20:46:07 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0)
 Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <CA+298Ui2=ZuzZb=4n2CZyJG2zRSr4wCe=Zdx9hAX5JpidskfSQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
archived-at: Thu, 13 Jul 2017 18:46:12 -0000

On 13.07.2017 20:42, Paul Hammant wrote:
> A Janitor process that runs independently of Apache isn't a /paradigm
> shift/ but it is a huge amount of work to production harden, even if
> it was done in today's new hotness Go or Rust.  As is the minefield of
> maintaining a list that's persistent of things yet to do post
> response. I'm on he Fossil list too, and I see infrequent emails about
> how SqlLite can barf in some situations.

Agreed. That's why I didn't propose this. I proposed spawning off a
daemon that would post-process _one_ commit and exit. It could do all
sorts of analysis of the content and finding the best (for some
definition of "best") source for the delta, etc.


> A cron type thing that's allowed to bisect commits for the repo
> looking for the earliest one that has a property set
> (deferred-delta=true), and removing that property when it's made the
> delta?

That'd work too, but needs administrator intervention. Spawning a daemon
process doesn't.

-- Brane