From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <9front-bounces@9front.inri.net> X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.4 Received: from 9front.inri.net (9front.inri.net [168.235.81.73]) by inbox.vuxu.org (Postfix) with ESMTP id D4B3325A04 for ; Wed, 8 May 2024 21:48:38 +0200 (CEST) Received: from simple-cc.openbsd.amsterdam ([46.23.94.210]) by 9front; Wed May 8 15:46:48 -0400 2024 Received: from localhost (simple-cc.openbsd.amsterdam [local]) by simple-cc.openbsd.amsterdam (OpenSMTPD) with ESMTPA id b7e80d97 for <9front@9front.org>; Wed, 8 May 2024 21:46:43 +0200 (CEST) Date: Wed, 8 May 2024 21:46:43 +0200 From: "Roberto E. Vargas Caballero" To: 9front@9front.org Message-ID: References: <328dc131-044d-408d-a040-512a44ae6e7b@fjrhome.net> <9df183e7-7a94-4d58-9a68-2dbc0e73018f@posixcafe.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9df183e7-7a94-4d58-9a68-2dbc0e73018f@posixcafe.org> List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: secure structured ActivityPub persistence CSS frontend Subject: Re: [9front] Enabling a service Reply-To: 9front@9front.org Precedence: bulk Hi, On Wed, May 08, 2024 at 11:10:00AM -0500, Jacob Moody wrote: > On 5/8/24 10:49, Frank D. Engel, Jr. wrote: > > How did it work for Venti when there were multiple users? > > My understanding of venti is somewhat limited to take my explanation with a grain of salt. > If you have divergent fossils using the same venti you will get divergent root scores, they > become two paths that have to be merged manually. Yes, that is what would happen. Fossil is not designed at all to be a distributed shared file system. If you back two fossil fs to the same venti you will have two different fs, no merge, no conflict, no anything. > No matter how you cut you are going to have to deal with multiple people merging > their cache in to the single root of truth with potentially latent updates. > Either you have to serialize all mutations at the source of truth (and at that point > you are latent bound) or you have to be clever about merging. A lot of ink has been > spilled about this problem in the scope of web programming (CRDs iirc), perhaps > that may serve as some inspiration. I would suggest to take a look to AFS (Andrew File System, that I think had also an evoultion but I don't remember the name) and how it works, and the implications. Sometimes you can merge the changes, and other times you have to request human decisions. Regards,