RE: Git for games working group

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

On September 23, 2018 3:54 PM, John Austin wrote:
> On Sun, Sep 23, 2018 at 10:57 AM Randall S. Becker
> <rsbecker@nexbridge.com> wrote:
> >  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.
> 
> Great to hear -- once the code is in a bit better shape I can open it up on
> github. Cross platform is definitely one of my focuses. I'm currently
> implementing in Rust because it targets the same space as C and has great,
> near trivial, cross-platform support. What sorts of platforms are you
> interested in? Windows is my first target because that's where many game
> developers live.

I have looked at porting Rust to my two mid-to-large platforms which do not have a Rust port. I would prefer keeping within what git currently requires without adding dependencies, but I'd be happy to take a Rust prototype and translate it. My need is actually not for gamers, but in similar processes that gamers use. The following dependences are not available on the two platforms I have in mind: g++ or clang; 
And cmake (despite efforts by people on the platform to do ports). This puts me in a difficult spot with Rust. I understand you might want to use Rust's implied threating, so I would be willing to do the pthread work to make it happen in C.

> > 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.
> 
> Agreed -- I think this is all up to how the query endpoint and client is
> designed. A couple of different types of clients could be implemented,
> depending on the policies you want in place. One could have strict security
> that stored unlocked files with a-w, as mentioned. Another could be a
> weaker client, and simply warn developers when their current branch is in
> conflict.

Regards,
Randall