"GOT", but the "O" is a cute, smiling pufferfish. Index | Thread | Search

From:
Stefan Sperling <stsp@stsp.name>
Subject:
Re: Workflow question, maybe bug or unclear usage.
To:
Christian Weisgerber <naddy@mips.inka.de>
Cc:
gameoftrees@openbsd.org, Ted Bullock <tbullock@comlore.com>
Date:
Thu, 27 Jan 2022 23:47:21 +0100

Download raw body.

Thread
On Thu, Jan 27, 2022 at 11:15:52PM +0100, Christian Weisgerber wrote:
> Stefan Sperling:
> 
> > naddy, would you still prefer a separate variable? I don't mind.
> 
> No, if millert@ has no objection then I don't either.
> 
> I don't understand the call path maze, but I can also confirm that
> the patch fixes the problem.
> 
> BTW, I noticed that OpenBSD supports ReaddirPlus, it just isn't
> enabled by default; see the mount_nfs(8) -l option.  Enabling it
> also fixes the d_type problem, as expected, but doesn't make any
> speed difference.

The fix has been committed.

I would advise against modifying work trees with clients that access the
work tree over NFS. This might trigger problems if multiple clients
operate on the work tree in parallel for some reason. Got relies on
flock(2) to ensure exclusive access, and relies on "atomic" rename
behaviour while updating files with new content, which is not guaranteed
over NFS.

Sharing a work tree to other machines over read-only NFS is perfectly
safe. 'got status' will work even if run from other machines because
it does not lock the work tree. Though this means that it might show
inconsistent state or even error out on occasion if it happens to run
in parallel to other commands.
Most got commands will likely fail on a read-only work tree.

Ideally, each machine should have its own local repo clone and source tree.
But I understand that this is not always feasible.