On Sun, Sep 23, 2018 at 01:56:37PM -0400, Randall S. Becker wrote: > 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 think that this is the way that we would prefer it, too. Ideally users outside of those who have Git LFS installed or those that are regular users of it should be able to interoperate with those using the global graph. We're thinking a lot about what should go into the next major version of Git LFS, v3.0.0, and this seems a good candidate to me. We'd also want to figure out how to transition v2.0.0-era locks into the new global graph, but that seems a topic for a later discussion. Thanks, Taylor
