From a92427c0d32a65a47672e97a4badb325a23a6f1a Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 27 Sep 2021 14:14:52 -0400 Subject: [PATCH] comment --- ...ment_7_463e336fd7f2cb21eff2d87d25851c39._comment | 13 +++++++++++++ 1 file changed, 13 insertions(+) create mode 100644 doc/todo/lockContent_for_special_remotes/comment_7_463e336fd7f2cb21eff2d87d25851c39._comment diff --git a/doc/todo/lockContent_for_special_remotes/comment_7_463e336fd7f2cb21eff2d87d25851c39._comment b/doc/todo/lockContent_for_special_remotes/comment_7_463e336fd7f2cb21eff2d87d25851c39._comment new file mode 100644 index 0000000000..d0f5a3cf9f --- /dev/null +++ b/doc/todo/lockContent_for_special_remotes/comment_7_463e336fd7f2cb21eff2d87d25851c39._comment @@ -0,0 +1,13 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 7""" + date="2021-09-27T18:11:49Z" + content=""" +It certainly must be possible to use a git-annex remote to handle locking +for special remotes, after all if you inverted control and had that +git-annex repository communicating to the user's reposities and telling +them when to delete from the special remote, that would be race safe. + +But it seems that the usual git-annex remote operations are not sufficient +to do it. It would need some new operations tailored to support it. +"""]]