On September 17, 2018 9:55 AM Taylor Blau wrote: > On Sun, Sep 16, 2018 at 04:55:13PM +0200, Ævar Arnfjörð Bjarmason wrote: > > In the hypothetical git-annex-like case (simplifying a bit for the > > purposes this explanation), for every FILE in your tree you have a > > corresponding FILE.lock file, but it's not a boolean, but a log of > > who's asked for locks, i.e. lines of: > > > > <repository UUID> <ts> <state> <who (email?)> <explanation?> > > > > E.g.: > > > > $ cat Makefile.lock > > my-random-per-repo-id 2018-09-15 1 ava...@gmail.com "refactoring > all Makefiles" > > my-random-per-repo-id 2018-09-16 0 ava...@gmail.com "done!" > > > > This log is append-only, when clients encounter conflicts there's a > > merge driver to ensure that all updates are kept. > > Certainly. I think that there are two things that aren't well expressed under > this mechanism: > > 1. Having a log of locks held against that (a) file doesn't prevent us > from introducing merge conflicts at the <file>.lock level, so we're > reliant upon the caller first running 'git pull' and hoping that no > one beats them out to locking and pushing their lock. > > 2. Multi-file locks, e.g., "I need to lock file(s) X, Y, and Z > together." This isn't possible in Git LFS today with the existing "git > lfs lock" command (I had to check, but it takes only _one_ filename as > its argument). > > Perhaps it would be nice to support something like this someday in > Git LFS, but I think we would have to reimagine how this would look > in your file.lock scheme.
I have an interest in this particular scheme, so am looking at porting both golang and git-lfs over to my platform (HPE-NonStop). The multi-file lock problem can be addressed through a variety of cooperative scheme, and if I get the port, I'm hoping to contribute something to solve it (that's a big IF at this point in time) - there are known mutex patterns to solve this AFAIR. My own community has a similar requirement, so I'm investigating. Cheers, Randall
