diff options
author | Joey Hess <joey@kitenet.net> | 2012-09-17 21:05:50 -0400 |
---|---|---|
committer | Joey Hess <joey@kitenet.net> | 2012-09-17 21:05:50 -0400 |
commit | 3c22977e44b852ecc4d1ad2d728e5dc9071952ae (patch) | |
tree | ef2f0d8e1635c49dea2bf4d4876e25a46981f058 /doc/design/assistant/syncing.mdwn | |
parent | 7a86dc944306af4d0a707631b03ef93941ecc1be (diff) |
deferred downloads
Now when a download is queued and there's no known remote to get it from,
it's added to a deferred download list, which will be retried later.
The Merger thread tries to queue any deferred downloads when it receives
a push to the git-annex branch.
Note that the Merger thread now also forces an update of the git-annex
branch. The assistant was not updating this branch before, and it saw a
(mostly) correct view of state, but now that incoming pushes go to
synced/git-annex, it needs to be merged in.
Diffstat (limited to 'doc/design/assistant/syncing.mdwn')
-rw-r--r-- | doc/design/assistant/syncing.mdwn | 6 |
1 files changed, 5 insertions, 1 deletions
diff --git a/doc/design/assistant/syncing.mdwn b/doc/design/assistant/syncing.mdwn index 222adae5e..b9c6016b2 100644 --- a/doc/design/assistant/syncing.mdwn +++ b/doc/design/assistant/syncing.mdwn @@ -39,7 +39,7 @@ all the other git clones, at both the git level and the key/value level. Possible solution: C could record a download intent. (Similar to a failed download, but with an unknown source.) When C next receives a git-annex branch push, it could try to requeue downloads that it has such intents - registered for. + registered for. **done** Note that this solution won't cover use cases the other does. For example, connect a USB drive A; B syncs files from it, and then should pass them to C. @@ -85,6 +85,10 @@ all the other git clones, at both the git level and the key/value level. need to use the TransferScanner, if we get and check a list of the changed files. * [[use multiple transfer slots|todo/Slow_transfer_for_a_lot_of_small_files.]] +* The TransferQueue's list of deferred downloads could theoretically + grow without bounds in memory. Limit it to a given number of entries, + and fall back to some other method -- either storing deferred downloads + on disk, or perhaps scheduling a TransferScanner run to get back into sync. ## data syncing |