Regarding integration into LFS, I'd like to build the library in such
a way that it would easy to bundle with LFS (so they could share the
same git hooks), but also make it flexible enough to work for other
workflows.
On Sun, Sep 23, 2018 at 12:53 PM John Austin <j...@astrangergravity.com> wrote:
>
> 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.

Reply via email to