All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Randall S. Becker" <rsbecker@nexbridge.com>
To: "'Taylor Blau'" <me@ttaylorr.com>,
	"'Ævar Arnfjörð Bjarmason'" <avarab@gmail.com>
Cc: "'John Austin'" <john@astrangergravity.com>,
	<git@vger.kernel.org>, <sandals@crustytoothpaste.net>,
	<larsxschneider@gmail.com>, <pastelmobilesuit@github.com>,
	"'Joey Hess'" <id@joeyh.name>
Subject: RE: Git for games working group
Date: Mon, 17 Sep 2018 10:01:19 -0400	[thread overview]
Message-ID: <000f01d44e8e$ec37f600$c4a7e200$@nexbridge.com> (raw)
In-Reply-To: <20180917135525.GF71477@syl>

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 avarab@gmail.com "refactoring
> all Makefiles"
> >     my-random-per-repo-id 2018-09-16 0 avarab@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



  reply	other threads:[~2018-09-17 14:01 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-14 17:55 Git for games working group John Austin
2018-09-14 19:00 ` Taylor Blau
2018-09-14 21:09   ` John Austin
2018-09-15 16:40     ` Taylor Blau
2018-09-16 14:55       ` Ævar Arnfjörð Bjarmason
2018-09-16 20:49         ` John Austin
2018-09-17 13:55         ` Taylor Blau
2018-09-17 14:01           ` Randall S. Becker [this message]
2018-09-17 15:00           ` Ævar Arnfjörð Bjarmason
2018-09-17 15:57             ` Taylor Blau
2018-09-17 16:21               ` Randall S. Becker
2018-09-17 16:47             ` Joey Hess
2018-09-17 17:23               ` Ævar Arnfjörð Bjarmason
2018-09-23 17:28                 ` John Austin
2018-09-23 17:56                   ` Randall S. Becker
2018-09-23 19:53                     ` John Austin
2018-09-23 19:55                       ` John Austin
2018-09-23 20:43                       ` Randall S. Becker
2018-09-24 14:01                       ` Taylor Blau
2018-09-24 15:34                         ` John Austin
2018-09-24 19:58                           ` Taylor Blau
2018-09-25  4:05                             ` John Austin
2018-09-25 20:14                               ` Taylor Blau
2018-09-24 13:59                     ` Taylor Blau
2018-09-14 21:13   ` John Austin
2018-09-16  7:56     ` David Aguilar
2018-09-17 13:48       ` Taylor Blau
2018-09-14 21:21 ` Ævar Arnfjörð Bjarmason
2018-09-14 23:36   ` John Austin
2018-09-15 16:42     ` Taylor Blau
2018-09-16 18:17       ` John Austin
2018-09-16 22:05         ` Jonathan Nieder
2018-09-17 13:58           ` Taylor Blau
2018-09-17 15:58             ` Jonathan Nieder
2018-10-03 12:28               ` Thomas Braun

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='000f01d44e8e$ec37f600$c4a7e200$@nexbridge.com' \
    --to=rsbecker@nexbridge.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=id@joeyh.name \
    --cc=john@astrangergravity.com \
    --cc=larsxschneider@gmail.com \
    --cc=me@ttaylorr.com \
    --cc=pastelmobilesuit@github.com \
    --cc=sandals@crustytoothpaste.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.