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

use per-remote metadata storage for S3 version ID

Browse source 
Since the same key can be stored in a versioned S3 bucket multiple times
with different version IDs, this allows tracking them all. Not currently
needed, but if we ever want to drop from a versioned S3 bucket, we'll
need to know them all.

This commit was supported by the NSF-funded DataLad project.
This commit is contained in:
Joey Hess 2018-08-31 13:12:58 -04:00
parent 5c99f6247e
commit b3d42283ad
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
4 changed files with 33 additions and 20 deletions
Download patch file Download diff file Expand all files Collapse all files

4
doc/todo/versioning_in_export_remotes.mdwn
View file

@ -82,7 +82,3 @@ 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. 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
the bucket multiple times under different version IDs.