mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

update

Browse source
This commit is contained in:
Joey Hess 2012-10-18 15:56:52 -04:00
parent ee9e0702a2
commit 0c6a1ec87d
1 changed files with 11 additions and 8 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

19
doc/design/assistant/transfer_control.mdwn
View file

@ -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**