| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Currently only the web special remote is readonly, but it'd be possible to
also have readonly drives, or other remotes. These are handled in the
assistant by only downloading from them, and never trying to upload to
them.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Since it turned out to make sense to always scan all remotes on startup,
there's no need to persist the info about which have been scanned.
|
| | |
|
| |
|
|
| |
Or when a remote first becomes available after startup.
|
| | |
|
| |
|
|
|
|
|
| |
The problem with using it here is that, if a removable drive is scanned
and gets disconnected during the scan, testing for all the files will
indicate it doesn't have them, and the scan is logged as completed
successfully, without necessary transfers being queued.
|
| |
|
|
| |
of a remote
|
| | |
|
| |
|
|
|
|
| |
They're updated to show whether the activity succeeded or failed.
This adds several TODOs to the code to fix later.
|
| |
|
|
| |
Makes it easier to edit for consistent voice etc.
|
| | |
|
| |
|
|
|
|
| |
The fun part was making it move things from TransferQueue to currentTransfers
entirely atomically. Which will avoid inconsistent display if the WebApp
renders the current status at just the wrong time. STM to the rescue!
|
| |
|
|
| |
Now scanning runs fully interleaved with transferring.
|
| |
|
|
| |
Works.. could be more efficient.
|
| |
|
|
|
|
|
| |
Allow transfers to be added with blocking until the queue is sufficiently
small.
Better control over which end of the queue to add a transfer to.
|
| | |
|
|
|
Efficiently finding transfers that need to be done to get two repos back
in sync seems like an interesting problem.
|
Joey Hess