thoughts

doc/bugs/move_violates_numcopies/comment_5_4ef4c6180c71326faa814bb096dab500._comment

@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2018-04-10T22:39:30Z"
+ content="""
+Another way to approach this is: `move` should not make
+a situation worse, but is not required to make it better.
+
+That would allow moving a file from A to B when numcopies wants 2 copies
+but only one copy exists, because the file being on B is no worse than it
+being on A.
+
+But, if B already has a copy of the file, move would error rather than the
+current behavior of removing from A, when numcopies wants two copies.
+
+And, if B is untrusted (and A is not), or A has the file as required
+content, moving to B would also error, as in both situations it makes
+things worse.
+
+This seems better than the ideas above, because it keeps move a somewhat
+lowlevel operation, like it always has been, but no longer an unsafe one.
+It matches many of my uses of move, when perhaps I want more copies than I
+have, but can't currently spare the space (or am moving the file to a repo
+that will later let it get replicated elsewhere).
+
+It also means that after `git annex move --from`, the local repository will 
+always have the file present, rather than move sometimes failing before
+getting it due to numcopies. (And the converse with `--to`.)
+
+I think this is a small enough change from the current behavior of move
+that it can get away with not having a transition plan.
+"""]]