summaryrefslogtreecommitdiff
path: root/Assistant/Sync.hs
Commit message (Collapse)AuthorAge
* sync, assistant: Sync with remotes that have annex-ignore setGravatar Joey Hess2013-04-22
| | | | | | | | This is so git remotes on servers without git-annex installed can be used to keep clients' git repos in sync. This is a behavior change, but since annex-sync can be set to disable syncing with a remote, I think it's acceptable.
* syncNewRemote is not only used for new remotes; rename to syncRemoteGravatar Joey Hess2013-04-08
|
* refactor alert button creation codeGravatar Joey Hess2013-04-04
|
* avoid showing web special remote in sync alertGravatar Joey Hess2013-03-28
|
* avoid displaying alert when syncing only to removable drives and all not ↵Gravatar Joey Hess2013-03-27
| | | | attached
* fix inverted logic in filtering failed remotesGravatar Joey Hess2013-03-27
|
* don't show sync failure for drive that's not plugged inGravatar Joey Hess2013-03-18
|
* webapp: Improved alerts displayed when syncing with remotes, and when ↵Gravatar Joey Hess2013-03-18
| | | | syncing with a remote fails.
* unify two similar alertsGravatar Joey Hess2013-03-18
|
* avoid false alert about syncing with xmpp remoteGravatar Joey Hess2013-03-06
|
* avoid too early scanning for xmppremotesGravatar Joey Hess2013-03-06
|
* tag xmpp pushes with jidGravatar Joey Hess2013-03-06
| | | | | | | | | | This fixes the issue mentioned in the last commit. Turns out just collecting UUID of clients behind a XMPP remote is insufficient (although I should probably still do it for other reasons), because a single remote repo might be connected via both XMPP and local pairing. So a way is needed to know when a push was received from any client using a given XMPP remote over XMPP, as opposed to via ssh.
* assistant: Get back in sync with XMPP remotes after network reconnection, ↵Gravatar Joey Hess2013-03-06
| | | | | | | | | | | | | | | | | | | | | and on startup. Make manualPull send push requests over XMPP. When reconnecting with remotes, those that are XMPP remotes cannot immediately be pulled from and scanned, so instead maintain a set of (probably) desynced remotes, and put XMPP remotes on it. (This set could be used in other ways later, if we can detect we're out of sync with other types of remotes.) The merger handles detecting when a XMPP push is received from a desynced remote, and triggers a scan then, if they have in fact diverged. This has one known bug: A single XMPP remote can have multiple clients behind it. When this happens, only the UUID of one client is recorded as the UUID of the XMPP remote. Pushes from the other XMPP clients will not trigger a scan. If the client whose UUID is expected responds to the push request, it'll work, but when that client is offline, we're SOL.
* git subcommand cleanupGravatar Joey Hess2013-03-03
| | | | | | Pass subcommand as a regular param, which allows passing git parameters like -c before it. This was already done in the pipeing set of functions, but not the command running set.
* assistant: Fix syncing to just created ssh remotes.Gravatar Joey Hess2012-12-06
| | | | | This got broken when I optimised reconnecting with remotes, to not do a full scan if the remote was not diverged.
* show when a buddy is already pairedGravatar Joey Hess2012-11-10
|
* avoid sending xmpp push notifications when not pushing to any remotesGravatar Joey Hess2012-11-10
|
* full-on git-annex assistant syncing now works over XMPP!Gravatar Joey Hess2012-11-10
| | | | | | | | | | I decided to use the fallback push mode from the beginning for XMPP, since while it uses some ugly branches, it avoids the possibility of a normal push failing, and needing to pull and re-push. Due to the overhead of XMPP, and the difficulty of building such a chain of actions due to the async implementation, this seemed reasonable. It seems to work great!
* separate data type for push stagesGravatar Joey Hess2012-11-10
| | | | This improves type safety.
* add canpush xmpp commandGravatar Joey Hess2012-11-09
|
* blog for the dayGravatar Joey Hess2012-11-08
|
* refactor XMPP clientGravatar Joey Hess2012-11-03
|
* where indentationGravatar Joey Hess2012-10-31
|
* assistant: Fix syncing local drives.Gravatar Joey Hess2012-10-30
| | | | | Amoung other things, this makes it immediately sync files from a removable drive when it's added.
* webapp: Make an initial, empty commit so there is a master branchGravatar Joey Hess2012-10-30
| | | | Several things only happen when on a branch, so make sure we're on one.
* pushed Assistant monad down into DaemonStatus codeGravatar Joey Hess2012-10-30
| | | | | | Currently have three old versions of functions that more reworking is needed to remove: getDaemonStatusOld, modifyDaemonStatusOld_, and modifyDaemonStatusOld
* split ScanRemotes and liftedGravatar Joey Hess2012-10-29
|
* split and lift Assistant.PushesGravatar Joey Hess2012-10-29
|
* lift alertWhileGravatar Joey Hess2012-10-29
|
* more liftingGravatar Joey Hess2012-10-29
|
* lifted Assistant.Sync into Assistant monadGravatar Joey Hess2012-10-29
| | | | lots of nice cleanups
* Assistant monad, stage 2.5Gravatar Joey Hess2012-10-29
| | | | | | | | | | Converted several threads to run in the monad. Added a lot of useful combinators for working with the monad. Now the monad includes the name of the thread. Some debugging messages are disabled pending converting other threads.
* add git-annex branch commit when assistant is syncingGravatar Joey Hess2012-10-28
| | | | Seems nothing else ensures the branch is committed anymore.
* pull from one of the remotes in a push notificationGravatar Joey Hess2012-10-24
| | | | | Still need to do something about transfer queueing, however. This could be a real can of worms.
* initial implementation of XMPP push notifier (untested)Gravatar Joey Hess2012-10-24
| | | | | | | Lacking error handling, reconnection, credentials configuration, and doesn't actually do anything when it receives an incoming notification. Other than that, it might work! :)
* added push notifier thread, currently a no-opGravatar Joey Hess2012-10-24
| | | | | | | | | | | Hooked up everything that needs to notify on pushes. Note that syncNewRemote does not notify. This is probably ok, and I'd need to thread more state through to make it do so. This is only set up to support a single push notification method; I didn't use a NotificationBroadcaster. Partly because I don't yet know what info about pushes needs to be communicated, so my data types are only preliminary.
* better variable nameGravatar Joey Hess2012-10-14
|
* use gitRepoGravatar Joey Hess2012-10-12
|
* fix breakage caught by test suiteGravatar Joey Hess2012-09-21
| | | | | Can't use show-ref --tags --branches, as that omits remote branches. Instead, filter out the synced refs directly.
* better name for fallback sync refsGravatar Joey Hess2012-09-16
| | | | | | | | | | | Don't expose these as branches in refs/heads/. Instead hide them away in refs/synced/ where only show-ref will find them. Make unused only look at branches and tags, not these other things, so it won't care if some stale sync ref used to use a file. This means they don't need to be deleted, which could have led to an incoming sync being missed.
* ensure outgoing sync pushes always succeed when repo is accessibleGravatar Joey Hess2012-09-16
| | | | | | | | | The fallback branches pushed to contain the uuid of the pusher, which is ugly. That's why syncing doesn't normally use this method. The merger deletes fallback branches after merging them, to contain the ugliness, and so unused doesn't look at data from these branches. (The fallback git-annex branch is left behind for now.)
* hlintGravatar Joey Hess2012-09-13
|
* pairing probably works now (untested)Gravatar Joey Hess2012-09-10
|
* display errors when any named thread crashesGravatar Joey Hess2012-09-06
|
* improve syncing support for special remotesGravatar Joey Hess2012-09-04
| | | | | | Avoid trying to git push/pull to special remotes, but still do transfer scans of them, after git pull from any other remotes, so we know about any values that have been placed on them.
* scan multiple remotes in one passGravatar Joey Hess2012-08-26
| | | | | | | | | | | | | | | | | | | | | | | | | 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.
* run full transfer scan on all remotes at startupGravatar Joey Hess2012-08-24
| | | | Or when a remote first becomes available after startup.
* keep logs of failed transfers, and requeue them when doing a non-full scanGravatar Joey Hess2012-08-23
| | | | of a remote
* better nameGravatar Joey Hess2012-08-22
|
* avoid unnecessary transfer scans when syncing a disconnected remoteGravatar Joey Hess2012-08-22
| | | | | | | | | | | | | | | | | | | | 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.