| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Found a very cheap way to determine when a disconnected remote has
diverged, and has new content that needs to be transferred: Piggyback on
the git-annex branch update, which already checks for divergence.
However, this does not check if new content has appeared locally while
disconnected, that should be transferred to the remote.
Also, this does not handle cases where the two git repos are in sync,
but their content syncing has not caught up yet.
This code could have its efficiency improved:
* When multiple remotes are synced, if any one has diverged, they're
all queued for transfer scans.
* The transfer scanner could be told whether the remote has new content,
the local repo has new content, or both, and could optimise its scan
accordingly.
|
| |
|
|
|
|
| |
A paused transfer's thread keeps running, keeping the slot in use.
This is intentional; pausing a transfer should not let other
queued transfers to run in its place.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This seems to work pretty well.
Handled the process groups like this:
- git-annex processes started by the assistant for transfers are run in their
own process groups.
- otherwise, rely on the shell to allocate a process group for git-annex
There is potentially a problem if some other program runs git-annex
directly (not using sh -c) The program and git-annex would then be in
the same process group. If that git-annex starts a transfer and it's
canceled, the program would also get killed. May or may not be a desired
result.
Also, the new updateTransferInfo probably closes a race where it was
possible for the thread id to not be recorded in the transfer info, if
the transfer info file from the transfer process is read first.
|
| | |
|
| | |
|
| |
|
|
|
| |
Rather than using bootstrap's client-side closing.
Now closed alerts stay closed.
|
| | |
|
| |
|
|
|
|
| |
They're updated to show whether the activity succeeded or failed.
This adds several TODOs to the code to fix later.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
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!
|
| |
|
|
|
|
| |
I've convinced myself that nothing in DaemonStatus can deadlock,
as it always keepts the TMVar full. That was the only reason it was in the
Annex monad.
|
| |
|
|
|
| |
First use of it is to make the status checkpointer thread block until
there is really a change to the status.
|
| | |
|
| |
|
|
|
|
| |
There's still a bug; if the child updates its transfer info file,
then the data from it will superscede the TransferInfo, losing the
info that we should wait on this child.
|
| |
|
|
| |
finally!
|
| |
|
|
|
|
|
| |
Added knownRemotes to DaemonStatus. This list is not entirely trivial to
calculate, and having it here should make it easier to add/remove remotes
on the fly later on. It did require plumbing the daemonstatus through to
some more threads.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Currently wakes up once a day, and does nothing. :)
|
| | |
|
| | |
|
| |
|
|
|
| |
Also afterLastDaemonRun, with 10 minute slop to handle majority of clock
skew issues.
|
| |
|
Joey Hess