RE: Git for games working group

["Randall S. Becker" <rsbecker@nexbridge.com>]

On September 23, 2018 1:29 PM, John Austin wrote:
> I've been putting together a prototype file-locking implementation for a
> system that plays better with git. What are everyone's thoughts on
> something like the following? I'm tentatively labeling this system git-sync or
> sync-server. There are two pieces:
> 
> 1. A centralized repository called the Global Graph that contains the union git
> commit graph for local developer repos. When Developer A makes a local
> commit on branch 'feature', git-sync will automatically push that new commit
> up to the global server, under a name-spaced
> branch: 'developera_repoabcdef/feature'. This can be done silently as a
> force push, and shouldn't ever interrupt the developer's workflow.
> Simple http queries can be made to the Global Graph, such as "Which
> commits descend from commit abcdefgh?"
> 
> 2. A client-side tool that queries the Global Graph to determine when your
> current changes are in conflict with another developer. It might ask "Are
> there any commits I don't have locally that modify lockable_file.bin?". This
> could either be on pre-commit, or for more security, be part of a read-only
> marking system ala Git LFS. There wouldn't be any "lock" per say, rather, the
> client could refuse to modify a file if it found other commits for that file in the
> global graph.
> 
> The key here is the separation of concerns. The Global Graph is fairly
> dimwitted -- it doesn't know anything about file locking. But it provides a
> layer of information from which we can implement file locking on the client
> side (or perhaps other interesting systems).
> 
> Thoughts?

I'm encouraged of where this is going. I might suggest "sync" is the wrong name here, with "mutex" being slightly better - I would even like to help with your effort and have non-unixy platforms I'd like to do this on.

Having this separate from git LFS is an even better idea IMO, and I would suggest implementing this using the same set of build tools that git uses so that it is broadly portable, unlike git LFS. Glad to help there too.

I would suggest that a higher-level grouping mechanism of resource groups might be helpful - as in "In need this directory" rather than "I need this file". Better still, I could see "I need all objects in this commit-ish", which would allow a revert operation to succeed or fail atomically while adhering to a lock requirement.

One bit that traditional lock-brokering systems implement involve forcing security attribute changes - so an unlocked file is stored as chmod a-w to prevent accidental modification of lockables, when changing that to chmod ?+w when a lock is acquired. It's not perfect, but does catch a lot of errors.

Cheers,
Randall