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

deferred downloads

Browse source 
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.
This commit is contained in:
Joey Hess 2012-09-17 21:05:50 -04:00
parent 7a86dc9443
commit 3c22977e44
4 changed files with 76 additions and 37 deletions
Download patch file Download diff file Expand all files Collapse all files

6
doc/design/assistant/syncing.mdwn
View file

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