From: "Randall S. Becker" <rsbecker@nexbridge.com>
To: "'John Austin'" <john@astrangergravity.com>,
"'Ævar Arnfjörð Bjarmason'" <avarab@gmail.com>
Cc: <id@joeyh.name>, "'Taylor Blau'" <me@ttaylorr.com>,
<git@vger.kernel.org>,
"'brian m. carlson'" <sandals@crustytoothpaste.net>,
"'Lars Schneider'" <larsxschneider@gmail.com>,
<pastelmobilesuit@github.com>
Subject: RE: Git for games working group
Date: Sun, 23 Sep 2018 13:56:37 -0400 [thread overview]
Message-ID: <000501d45366$cf437060$6dca5120$@nexbridge.com> (raw)
In-Reply-To: <CA+AhR6doYuwoucdcN9aKw7-HxgR-qa6OiN4Dnzcy5rifL8PYvg@mail.gmail.com>
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
next prev parent reply other threads:[~2018-09-23 18:03 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
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 [this message]
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='000501d45366$cf437060$6dca5120$@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).