From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from yow.a-b.xyz ([45.32.152.219]) by ewsd; Thu Feb 20 06:21:45 EST 2020
Received: 
	by yow.a-b.xyz (OpenSMTPD) with ESMTPSA id d6304d87 (TLSv1.2:ECDHE-RSA-AES256-SHA:256:NO)
	for <9front@9front.org>;
	Thu, 20 Feb 2020 12:21:37 +0100 (CET)
Message-ID: <5F595370862843BBA0E8BD297C6789AE@a-b.xyz>
To: 9front@9front.org
Subject: Re: [9front] Help wanted tracking down a bug in divergefs code [unionfs]
Date: Thu, 20 Feb 2020 12:21:36 +0100
From: kvik@a-b.xyz
In-Reply-To: <360b4425-5351-23a5-239b-f3300f721c7a@qs.co.nz>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: wrapper map/reduce-based polling manager 

> I see why but personally I don't like the intermediate mount
> point requirement.

I'm not a fan either; unionfs already detects the loop and
could perform the bind trick behind the scenes instead of
snipping the branch off.

> This is were divergefs comes in handy.  It presents to
> sysupdate a layout of the namespace consistant with the
> mercurial repository.
> 
> The ability to write back to the diverged directory is
> paramount to its success.

Quite neat!

Thanks for sharing this use case of divergefs, I'm always
interested in learning about namespace tactics being
deployed in the wild.