diff options
| -rw-r--r-- | doc/design/assistant/transfer_control.mdwn | 19 |
1 files changed, 11 insertions, 8 deletions
diff --git a/doc/design/assistant/transfer_control.mdwn b/doc/design/assistant/transfer_control.mdwn index 6e66f6cfe..d21081d34 100644 --- a/doc/design/assistant/transfer_control.mdwn +++ b/doc/design/assistant/transfer_control.mdwn @@ -13,6 +13,10 @@ something smart with such remotes. * preferred content settings made in the webapp (or in vicfg, or synced over) are not noticed while the assistant is running; it has to be restarted for them to take effect. +* The expensive scan currently makes one pass, dropping content at the same + time more uploads and downloads are queued. It would be better to drop as + much content as possible upfront, to keep the total annex size as small + as possible. How to do that without making two expensive scans? ### dropping no longer preferred content TODO @@ -20,11 +24,6 @@ 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 @@ -32,14 +31,18 @@ the same content, this gets tricky. Let's assume there are not.) with this is an expensive scan. (The rest of the items below come from analizing the terminals used in preferred content expressions.) **done** 2. renaming of a file (ie, moved to `archive/`) + (note that renaming a file can also make it become preferred content + again, and should cause it to be transferred in that case, which doesn't + happen either..) 3. we get a file (`in`, `copies`) **done** -4. some other repository drops the file (`in`, `copies` .. However, it's +4. we sent a file to a remote (`in`, `copies`) +5. 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) +6. `migrate` is used to change a backend (`inbackend`; unlikely) -That's all! Of these, 1, 2 and 3 are by far the most important. +That's all! Of these, 1-4 are by far the most important. ## specifying what data a remote prefers to contain **done** |