From 3a5d0402baab00b640bf2011bfa29c285deeb4d1 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Thu, 30 Aug 2018 15:39:28 -0400 Subject: [PATCH] update --- doc/todo/versioning_in_export_remotes.mdwn | 27 +++++++++++----------- 1 file changed, 13 insertions(+), 14 deletions(-) diff --git a/doc/todo/versioning_in_export_remotes.mdwn b/doc/todo/versioning_in_export_remotes.mdwn index 63c217e507..c624bb4de6 100644 --- a/doc/todo/versioning_in_export_remotes.mdwn +++ b/doc/todo/versioning_in_export_remotes.mdwn @@ -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