Merge branch 'master' of ssh://git-annex.branchable.com

This commit is contained in:
Joey Hess 2014-02-20 18:48:10 -04:00
commit d51d0a344f
8 changed files with 91 additions and 0 deletions

View file

@ -0,0 +1,9 @@
[[!comment format=mdwn
username="stp"
ip="84.56.21.11"
subject="Some suggestions"
date="2014-02-20T21:22:21Z"
content="""
So I think it should at least for --all look at the global numcopies setting. As this could be essential to prevent data-loss.
I agree that special working tree related numcopies don't need to be included.
"""]]

View file

@ -0,0 +1,14 @@
[[!comment format=mdwn
username="stp"
ip="84.56.21.11"
subject="Great improvements"
date="2014-02-20T21:20:15Z"
content="""
Thanks for clearing it up. It is still a bit confusing that you have to differentiate on the second run. (using --more) I probably view it as inconvenient as it make me have to remember the first and second time of running a command. I think it would be cleaner to have \"--incremental\" always skipping files and \"--incremental restart\" start from the beginning.
Ah great yeah they are different functions and should therefore not interfere. (fsck --fast --incremental)
Great that the checksum is back in and yeah I agree that it isn't really needed in the add command.
"""]]

View file

@ -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.
"""]]