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