summaryrefslogtreecommitdiff
path: root/Command/TransferKey.hs
Commit message (Collapse)AuthorAge
* mirror: New command, makes two repositories contain the same set of files.Gravatar Joey Hess2013-08-20
| | | | | | | | | | | | | | This is a simple approach for setting up a mirroring repository. It will work with any type of remotes. Mirror --from is more expensive than mirror --to in general. OTOH, mirror --from will get the file from any remote that has it, not only the named mirror remote. And if the named mirror remote is not the fastest available remote with a file, that can speed things up. It would be possible to make the assistant or watch command do a more dynamic mirroring, that didn't need to scan every time.
* --all for get, move, and copyGravatar Joey Hess2013-07-03
|
* connect existing meters to the transfer log for downloadsGravatar Joey Hess2013-04-11
| | | | | | | | | | | | | | Most remotes have meters in their implementations of retrieveKeyFile already. Simply hooking these up to the transfer log makes that information available. Easy peasy. This is particularly valuable information for encrypted remotes, which otherwise bypass the assistant's polling of temp files, and so don't have good progress bars yet. Still some work to do here (see progressbars.mdwn changes), but this is entirely an improvement from the lack of progress bars for encrypted downloads.
* add section metadata to all commandsGravatar Joey Hess2013-03-24
| | | | Not yet used .. mindless train work.
* implement transferkeys plumbing commandGravatar Joey Hess2013-03-19
|
* two types of byNameGravatar Joey Hess2013-03-05
| | | | | | | | Clean up from 5123a1a83aa3b954fe67629508bab5ccea0e4148. In some cases, looking up a remote by name even though it has no UUID is desirable. This includes git annex sync, which can operate on remotes without an annex, and XMPP pairing, which runs addRemote (with calls byName) before the UUID of the XMPP remote has been configured in git.
* quiet calls to transferkeyGravatar Joey Hess2012-09-24
|
* make the assistant retry failed transfersGravatar Joey Hess2012-09-23
| | | | | | | When a transfer fails, the progress info can be used to intelligently retry it. If the transfer managed to make some progress, but did not fully complete, then there's a good chance that a retry will finish it (or at least make more progress).
* add a progress callback to storeKey, and threaded it all the way throughGravatar Joey Hess2012-09-19
| | | | | | | | Transfer info files are updated when the callback is called, updating the number of bytes transferred. Left unused p variables at every place the callback should be used. Which is rather a lot..
* more descriptive name for oneshotGravatar Joey Hess2012-09-15
|
* add transferkey commandGravatar Joey Hess2012-08-24
Used by the assistant, rather than copy, this is faster because it avoids using git ls-files, avoids checking the location log redundantly, and runs in oneshot mode, avoiding making a commit to the git-annex branch for every file transferred.