scan multiple remotes in one pass

The expensive transfer scan now scans a whole set of remotes in one pass.
So at startup, or when network comes up, it will run only once.

Note that this can result in transfers from/to higher cost remotes being
queued before other transfers of other content from/to lower cost remotes.
Before, low cost remotes were scanned first and all their transfers came
first. When multiple transfers are queued for a key, the lower cost ones
are still queued first. However, this could result in transfers from slow
remotes running for a long time while transfers of other data from faster
remotes waits.

I expect to make the transfer queue smarter about ordering
and/or make it allow multiple transfers at a time, which should eliminate
this annoyance. (Also, it was already possible to get into that situation,
for example if the network was up, lots of transfers from slow remotes
might be queued, and then a disk is mounted and its faster transfers have
to wait.)

Also note that this means I don't need to improve the code in
Assistant.Sync that currently checks if any of the reconnected remotes
have diverged, and if so, queues scans of all of them. That had been very
innefficient, but now doesn't matter.

1 files changed, 2 insertions, 2 deletions

diff --git a/Assistant/Sync.hs b/Assistant/Sync.hs
index 35b300f39..499fc960c 100644
--- a/Assistant/Sync.hs
+++ b/Assistant/Sync.hs
@@ -28,8 +28,8 @@ import qualified Data.Map as M
  - 
  - First gets git in sync, and then prepares any necessary file transfers.
  -
- - An expensive full scan is queued when the git-annex branches of the
- - remotes have diverged from the local git-annex branch. Otherwise,
+ - An expensive full scan is queued when the git-annex branches of some of
+ - the remotes have diverged from the local git-annex branch. Otherwise,
  - it's sufficient to requeue failed transfers.
  -}
 reconnectRemotes :: ThreadName -> ThreadState -> DaemonStatusHandle -> ScanRemoteMap -> [Remote] -> IO ()