mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

all easy cases done

Browse source 
bup can't do it after all, because removeKey deletes the git branch. And
the rest seem too hard to tackle today.
This commit is contained in:
Joey Hess 2020-06-26 14:24:48 -04:00
parent 8b22e0bf37
commit 7fd20146e1
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
1 changed files with 31 additions and 7 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

38
doc/todo/lockContent_for_special_remotes.mdwn
View file

@ -1,13 +1,24 @@
Currently only Remote.Git implements lockContent. It seems like some other Support lockContent in more special remotes. This allows dropping
special remotes can lock content though: content from a special remote when the only copies are in other special
remotes.
(All the easy ones, eg read-only special remotes, are implemented already.)
* bup and git-lfs and tahoe can't drop content, so content is implicitly locked
* S3 has an object lock feature, I don't know if it would be usable for
this, but woth investigating.
* adb could use some shell trick perhaps
* It might be possible for an external remote to lock content, but it would * It might be possible for an external remote to lock content, but it would
be a tricky extension to the protocol, since lockContent needs to keep it be a tricky extension to the protocol, since lockContent needs to keep it
locked while running another action. locked while running another action. There would need to be separate
actions for locking and unlocking.
If this were implemented in git-annex, and some special remote program
didn't used to support it, and implemented REMOVE w/o checking a lock,
then making that program support lockContent would run the risk
of a misture of the old and new version being in use for the same remote,
which could result in data loss.
To avoid that, the author of the special remote would need to either
a) always do lock checking from the beginning or
b) wait long enough or document well enough to be sure that situation
never happens.
* directory could use fcntl locking * directory could use fcntl locking
@ -22,3 +33,16 @@ special remotes can lock content though:
locking, with various failure modes. And unlike a git-annex repo, locking, with various failure modes. And unlike a git-annex repo,
there's nowhere in a directory special remote to record information about there's nowhere in a directory special remote to record information about
locking problems with it. Getting this right seems hard.. locking problems with it. Getting this right seems hard..
* S3 has an object lock feature, I don't know if it would be usable for
this.
It would need a transition, with dropKey first failing when the object
lock was in place, and then once that git-annex was in use everywhere,
lockContent setting the object lock.
(S3 with versioning=yes already supports lockContent.)
* adb could use some shell trick perhaps.. But it would depend on doing
locking in /sdcard, which seems likely to be a massive ball of POSIX
incompliance and pain.