On September 23, 2018 1:29 PM, John Austin wrote: > I've been putting together a prototype file-locking implementation for a > system that plays better with git. What are everyone's thoughts on > something like the following? I'm tentatively labeling this system git-sync or > sync-server. There are two pieces: > > 1. A centralized repository called the Global Graph that contains the union git > commit graph for local developer repos. When Developer A makes a local > commit on branch 'feature', git-sync will automatically push that new commit > up to the global server, under a name-spaced > branch: 'developera_repoabcdef/feature'. This can be done silently as a > force push, and shouldn't ever interrupt the developer's workflow. > Simple http queries can be made to the Global Graph, such as "Which > commits descend from commit abcdefgh?" > > 2. A client-side tool that queries the Global Graph to determine when your > current changes are in conflict with another developer. It might ask "Are > there any commits I don't have locally that modify lockable_file.bin?". This > could either be on pre-commit, or for more security, be part of a read-only > marking system ala Git LFS. There wouldn't be any "lock" per say, rather, the > client could refuse to modify a file if it found other commits for that file in the > global graph. > > The key here is the separation of concerns. The Global Graph is fairly > dimwitted -- it doesn't know anything about file locking. But it provides a > layer of information from which we can implement file locking on the client > side (or perhaps other interesting systems). > > Thoughts? I'm encouraged of where this is going. I might suggest "sync" is the wrong name here, with "mutex" being slightly better - 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. 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. Cheers, Randall
