On Sun, Sep 23, 2018 at 10:57 AM Randall S. Becker <rsbec...@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 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.
