full analysis of ways content could stop being preferred and need to be dropped

Command/Vicfg.hs

@@ -125,7 +125,7 @@ genCfg cfg descs = unlines $ concat [intro, trust, groups, preferredcontent]
 			]
 
 		line setting u value =
-			[ com $ "(" ++ (fromMaybe "" $ M.lookup u descs) ++ ")"
+			[ com $ "(for " ++ (fromMaybe "" $ M.lookup u descs) ++ ")"
 			, unwords [setting, fromUUID u, "=", value]
 			]
 		lcom = map (\l -> if "#" `isPrefixOf` l then l else "#" ++ l)

doc/design/assistant/transfer_control.mdwn

@@ -8,17 +8,39 @@ But often the remote is just a removable drive or a cloud remote,
 that has a limited size. This page is about making the assistant do
 something smart with such remotes.
 
-## TODO
+## dropping no longer preferred content TODO
 
-* easy configuration of preferred content
-* Drop no longer preferred content.
-  - When a file is renamed, it might stop being preferred, so
-    could be checked and dropped. (If there's multiple links to
-    the same content, this gets tricky.)
-  - When a file is sent or received, the sender's preferred content
-    settings may change, causing it to be dropped from the sender.
-  - May also want to check for things to drop, from both local and remotes,
-    when doing the expensive trasfer scan.
+When a file is renamed, it might stop being preferred, so
+could be checked and dropped. (If there's multiple links to
+the same content, this gets tricky. Let's assume there are not.)
+
+* When a file is sent or received, the sender's preferred content
+  settings may change, causing it to be dropped from the sender.
+* May also want to check for things to drop, from both local and remotes,
+  when doing the expensive trasfer scan.
+
+### analysis of changes that can result in content no longer being preferred
+
+1. The preferred content expression can change, or a new repo is added, or
+   groups change. Generally, some change to global annex state. Only way to deal
+   with this is an expensive scan. (The rest of the items below come from
+   analizing the terminals used in preferred content expressions.)
+2. renaming of a file (ie, moved to `archive/`)
+3. some other repository gets the file (`in`, `copies`)
+4. some other repository drops the file (`in`, `copies` .. However, it's
+   unlikely that an expression would prefer content when *more* copies
+   exisited, and want to drop it when less do. That's nearly a pathological
+   case.)
+5. `migrate` is used to change a backend (`inbackend`; unlikely)
+
+That's all! Of these, 2 and 3 are by far the most important.
+
+Rename handling should certianly check 2. 
+
+One place to check for 3 is after transferring a file; but that does not
+cover all its cases, as some other repo could transfer the file. To fully
+handle 3, need to either use a full scan, or examine location log history
+when receiving a git-annex branch push.
 
 ## specifying what data a remote prefers to contain **done**
 
@@ -72,6 +94,10 @@ Some examples of using groups:
 The above is all well and good for those who enjoy boolean algebra, but
 how to configure these sorts of expressions in the webapp?
 
+Currently, we have a simple drop down list to select between a few
+predefined groups with pre-defined preferred content recipes. Is this good
+enough?
+
 ## the state change problem **done**
 
 Imagine that a trusted repo has setting like `not copies=trusted:2`
@@ -88,6 +114,4 @@ Or, expressions could be automatically rewritten to avoid the problem.
 Or, perhaps simulation could be used to detect the problem. Before
 dropping, check the expression. Then simulate that the drop has happened.
 Does the expression now make it want to add it? Then don't drop it!
-How to implement this simulation?
-
-> Solved, fwiw..
+**done**.. effectively using this approach.