RE: Git for games working group
- From
Randall S. Becker <rsbecker@nexbridge.com>
- Date
- Sep 23, 2018, 20:43 UTC
- Message-ID
- <000801d4537e$19351180$4b9f3480$@nexbridge.com>
- In-Reply-To
- <CA+AhR6c+D84sHhABRm4xf=5RWnpVEBXMXzdQxipYMS5bmkw9iQ@mail.gmail.com>
On September 23, 2018 3:54 PM, John Austin wrote:
Show 14 quoted lines
> 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.
Show 16 quoted lines
> > 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