Subject: RE: Git for games working group

From: "Randall S. Becker" <[email-masked]>
Date: Mon, 17 Sep 2018 10:01:19 -0400

On September 17, 2018 9:55 AM Taylor Blau wrote:
> On Sun, Sep 16, 2018 at 04:55:13PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > In the hypothetical git-annex-like case (simplifying a bit for the
> > purposes this explanation), for every FILE in your tree you have a
> > corresponding FILE.lock file, but it's not a boolean, but a log of
> > who's asked for locks, i.e. lines of:
> >
> >     <repository UUID> <ts> <state> <who (email?)> <explanation?>
> >
> > E.g.:
> >
> >     $ cat Makefile.lock
> >     my-random-per-repo-id 2018-09-15 1 [email-masked] "refactoring
> all Makefiles"
> >     my-random-per-repo-id 2018-09-16 0 [email-masked] "done!"
> >
> > This log is append-only, when clients encounter conflicts there's a
> > merge driver to ensure that all updates are kept.
> 
> Certainly. I think that there are two things that aren't well expressed
under
> this mechanism:
> 
>   1. Having a log of locks held against that (a) file doesn't prevent us
>      from introducing merge conflicts at the <file>.lock level, so we're
>      reliant upon the caller first running 'git pull' and hoping that no
>      one beats them out to locking and pushing their lock.
> 
>   2. Multi-file locks, e.g., "I need to lock file(s) X, Y, and Z
>      together." This isn't possible in Git LFS today with the existing
"git
>      lfs lock" command (I had to check, but it takes only _one_ filename
as
>      its argument).
> 
>      Perhaps it would be nice to support something like this someday in
>      Git LFS, but I think we would have to reimagine how this would look
>      in your file.lock scheme.

I have an interest in this particular scheme, so am looking at porting both
golang and git-lfs over to my platform (HPE-NonStop). The multi-file lock
problem can be addressed through a variety of cooperative scheme, and if I
get the port, I'm hoping to contribute something to solve it (that's a big
IF at this point in time) - there are known mutex patterns to solve this
AFAIR. My own community has a similar requirement, so I'm investigating.

Cheers,
Randall