From: Ilya_Shlyakhter Date: Thu, 15 Apr 2021 16:32:34 +0000 (+0000) Subject: Added a comment: lockContent for special remotes X-Git-Tag: archive/raspbian/10.20250416-2+rpi1~1^2~91^2~530 X-Git-Url: https://dgit.raspbian.org/?a=commitdiff_plain;h=3378f74fb07d1e6139ae6133c7b7506de901ddc2;p=git-annex.git Added a comment: lockContent for special remotes --- diff --git a/doc/todo/lockContent_for_special_remotes/comment_5_b006d6bca93a50e1f23a2b6d20584c91._comment b/doc/todo/lockContent_for_special_remotes/comment_5_b006d6bca93a50e1f23a2b6d20584c91._comment new file mode 100644 index 0000000000..11709cb449 --- /dev/null +++ b/doc/todo/lockContent_for_special_remotes/comment_5_b006d6bca93a50e1f23a2b6d20584c91._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="Ilya_Shlyakhter" + avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0" + subject="lockContent for special remotes" + date="2021-04-15T16:32:32Z" + content=""" +\"lockContent needs the remote to support an actual exclusive locking operation. Do you have an external special remote that could actually support that?\" -- I do, the [DNAnexus](https://www.dnanexus.com/) special remote. But it'd better if `git-annex` itself handled locking, so that one didn't have to trust each external remote's implementation. Locking for a remote doesn't have to be done through the remote itself; it can be done through another remote for which git-annex has built-in locking support. Doing it through the git remote itself seems simplest. + +\"ideas above seem to suffer from race conditions\" -- what is the race condition for syncing through the git-annex branch? If two people try to push to git-annex branch one will fail, and require a pull first. Let's say people P1 and P2 try to drop a file from remotes R1 and R2. They both cloned the repo from git remote G. P1's git-annex marks R1 untrusted on the git-annex branch, and pushes that branch to G. P2's git-annex marks R2 untrusted on the git-annex branch, and tries to push that branch to G, but fails, so has to pull first. Then P2's git-annex sees that R1 is now untrusted, and refuses to drop from R2. P1's git-annex finishes the drop from R1, then restores R1's trust level. + +This does require there to be a shared git remote G, but that's often the case. Maybe the URL of G could be stored in the remotes R1/R2 as contents of a special key? +"""]]