Added a comment: Some ideas for content sync

1 files changed, 14 insertions, 0 deletions

diff --git a/doc/bugs/git_annex_sync_--content_not_syncing_all_objects/comment_2_70804d50b07630fadfc029a22173c5a0._comment b/doc/bugs/git_annex_sync_--content_not_syncing_all_objects/comment_2_70804d50b07630fadfc029a22173c5a0._comment
new file mode 100644
index 000000000..4560e10d9
--- /dev/null
+++ b/doc/bugs/git_annex_sync_--content_not_syncing_all_objects/comment_2_70804d50b07630fadfc029a22173c5a0._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="stp"
+ ip="84.56.21.11"
+ subject="Some ideas for content sync"
+ date="2014-02-20T21:18:30Z"
+ content="""
+I agree that it is a tricky situation. The main issue I have is that archive preferred content expressions indicates that all versions are transferred, but when you (worst case) migrate full archives to other disks and just use git annex sync --content, you would loose all objects.
+
+I like the idea of --content --all as this would be consistent with other commands such as fsck for example.
+Still it seems with preferred content expressions only applying to working tree data that it would still miss \"copies=backup:2\" for example and only use working tree files. Which is misleading and could lead to dataloss in my opinion.
+
+So the best would probably be to let preferred content for number of copies at least work on all objects, either per default or when \"git annex sync --content --all\" is used. You wouldn't run that on usual repos, but definitely on backup, archive or similar repos.
+
+"""]]