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

update

Browse source
This commit is contained in:
Joey Hess 2018-08-30 15:39:28 -04:00
parent 19dcff2b71
commit 3a5d0402ba
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
1 changed files with 13 additions and 14 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

27
doc/todo/versioning_in_export_remotes.mdwn
View file

@ -33,14 +33,6 @@ won't be updated, as discussed above.
The haskell aws library does not seem to support enabling versioning when
creating a bucket, so it would need to be done from the web console.
If the user enables versioning in git-annex but forgets to enable it
in the bucket (or later suspends versioning in the bucket), it's no
big problem; old files will not be retained and git-annex will notice
this in the usual way (drop locking, fsck). So, it seems that initremote
does not need to check if the versioning=yes setting matches the bucket
configuration. For same reasons, it's ok to enable versioning for an
existing remote.
## final plan
Add an "appendOnly" field to Remote, indicating it retains all content stored
@ -65,14 +57,21 @@ configured. done
Use version IDs when retrieving keys and for checkpresent. done
TODO testing
## other considerations
Can public urls be generated using version IDs? The url has
"?versionId=" appended, but all the examples I've seen include S3
authorization headers.
When a file was deleted from an exported tree, and then put back
in a later exported tree, it might get re-uploaded even though the content
is still retained in the versioned remote. S3 might have a way to avoid
such a redundant upload, if so it could support using it.
If the user enables versioning in git-annex but forgets to enable it
in the bucket (or later suspends versioning in the bucket), it's no
big problem; old files will not be retained and git-annex will notice
this in the usual way (drop locking, fsck). So, it seems that initremote
does not need to check if the versioning=yes setting matches the bucket
configuration. For same reasons, it's ok to enable versioning for an
existing remote.
S3 does allow DELETE of a version of an object from a bucket. So it would
be possible to support `git annex drop` of old versions of a file from an
@ -84,8 +83,8 @@ so it would need to look at location tracking for all objects in the export
to find ones that some other repository dropped. And dropping of only
keys that are not used in the current export doesn't help because another
repository may have changed the exported tree and be relying on the dropped
key being present in the export. So, DELETE from an appendonly export
won't be supported, at least for now.
key being present in the export. Unless... Could export conflict resultion
somehow detect that?
Another reason DELETE from appendonly is not supported is that only one
version ID is stored per key, but the same key could have its content in