aboutsummaryrefslogtreecommitdiff
path: root/doc/todo
diff options
context:
space:
mode:
Diffstat (limited to 'doc/todo')
-rw-r--r--doc/todo/credentials-less_access_to_s3.mdwn11
-rw-r--r--doc/todo/find_unused_in_any_commit/comment_2_ab373440bf7bab9179fdfccf6da3e8a4._comment7
2 files changed, 18 insertions, 0 deletions
diff --git a/doc/todo/credentials-less_access_to_s3.mdwn b/doc/todo/credentials-less_access_to_s3.mdwn
new file mode 100644
index 000000000..39835ac1f
--- /dev/null
+++ b/doc/todo/credentials-less_access_to_s3.mdwn
@@ -0,0 +1,11 @@
+My situation is this: while i know i can *read and write* to [[special_remotes/S3]] fairly easily with the credentials, I cannot read from there from other remotes that do not have those credentials enabled.
+
+This seems to be an assumption deeply rooted in git-annex, specifically in `Remote/S3.hs:390`.
+
+It would be *very* useful to allow remotes to read from S3 transparently. I am aware of the tips mentionned in the comments of [[tips/publishing_your_files_to_the_public/]] that use the `addurl` hack, but this seems not only counter-intuitive, but also seem to add significant per-file overhead in the storage. It also requires running an extra command after every `git annex add` which is a problem if you are running the assistant that will add stuff behind your back.
+
+Besides, you never know if and when the file really is available on s3, so running addurl isn't necessarily accurate.
+
+How hard would it be to fix that in the s3 remote?
+
+Thanks! --[[anarcat]]
diff --git a/doc/todo/find_unused_in_any_commit/comment_2_ab373440bf7bab9179fdfccf6da3e8a4._comment b/doc/todo/find_unused_in_any_commit/comment_2_ab373440bf7bab9179fdfccf6da3e8a4._comment
new file mode 100644
index 000000000..8d489927f
--- /dev/null
+++ b/doc/todo/find_unused_in_any_commit/comment_2_ab373440bf7bab9179fdfccf6da3e8a4._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="eigengrau"
+ subject="comment 2"
+ date="2015-05-28T13:44:32Z"
+ content="""
+This would be absolutely awesome, because it would pruning away old data based on cut-offs. One could squash all history beyond some cut-off point. Or, probably better, one could preserve git history, but supply “git annex fsck” with a cut-off switch that specifies a date or time interval. All data referred to in commits older than the specified interval is then considered unused.
+"""]]