summaryrefslogtreecommitdiff
path: root/Assistant/Sync.hs
Commit message (Collapse)AuthorAge
* update my email address and homepage urlGravatar Joey Hess2015-01-21
|
* assistant: Fix one-way assistant->assistant sync in direct mode.Gravatar Joey Hess2014-06-16
| | | | | | | | | | | | | | When in direct mode, update the master branch after committing to the annex/direct/master branch. Also, update the synced/master branch. This fixes a topology A->B where both A and B are in direct mode and running the assistant, and a change is made to B. Before this fix, A pulled the changes from B, but since they were only on the annex/direct/master branch, it did not merge them. Note that I considered making the assistant merge the remotes/B/annex/direct/master, but decided to keep it simple and only merge the sync branches as before.
* assistant: Now detects immediately when other repositories push changes toGravatar Joey Hess2014-04-08
| | | | | | | | | | | | a ssh remote, and pulls. XMPP is no longer needed in this configuration! Requires the remote server have git-annex-shell with notifychanges support. (untested) This commit was sponsored by Geog Wechslberger.
* improve sync with xmpp and annex-ignoreGravatar Joey Hess2014-02-01
| | | | | | * sync --content: Honor annex-ignore configuration. * sync: Don't try to sync with xmpp remotes, which are only currently supported when using the assistant.
* Remotes can now be made read-only, by setting remote.<name>.annex-readonlyGravatar Joey Hess2014-01-02
|
* add post-repair actionsGravatar Joey Hess2013-10-29
|
* move code around and rename thread; no functional changesGravatar Joey Hess2013-10-29
|
* automatically launch git repository repairGravatar Joey Hess2013-10-27
| | | | | | | | | | | | | | | | | | Added a RemoteChecker thread, that waits for problems to be reported with remotes, and checks if their git repository is in need of repair. Currently, only failures to sync with the remote cause a problem to be reported. This seems enough, but we'll see. Plugging in a removable drive with a repository on it that is corrupted does automatically repair the repository, as long as the corruption causes git push or git pull to fail. Some types of corruption do not, eg missing/corrupt objects for blobs that git push doesn't need to look at. So, this is not really a replacement for scheduled git repository fscking. But it does make the assistant more robust. This commit is sponsored by Fernando Jimenez.
* moved code out of webappGravatar Joey Hess2013-10-26
| | | | | No code changes, aside from some changes to lifting in code that turned out to be able to run in Assistant rather than Handler.
* only sync with local repos that are currently available (and only fsck them too)Gravatar Joey Hess2013-10-14
|
* cronner: run jobs triggered by remotes becoming connected (untested)Gravatar Joey Hess2013-10-13
|
* include HEAD in CanPush shasGravatar Joey Hess2013-05-21
|
* XMPP: Avoid redundant and unncessary pushes. Note that this breaks ↵Gravatar Joey Hess2013-05-21
| | | | compatibility with previous versions of git-annex, which will refuse to accept any XMPP pushes from this version.
* add uuid to all xmpp messagesGravatar Joey Hess2013-04-30
| | | | | | | | | | | | | | | | | | (Except for the actual streaming of receive-pack through XMPP, which can only run once we've gotten an appropriate uuid in a push initiation message.) Pushes are now only initiated when the initiation message comes from a known uuid. This allows multiple distinct repositories to use the same xmpp address. Note: This probably breaks initial push after xmpp pairing, because at that point we may not know about the paired uuid, and so reject the push from it. It won't break in simple cases, because the annex-uuid of the remote is checked. However, when there are multiple clients behind a single xmpp address, only uuid of the first is recorded in annex-uuid, and so any pushes from the others will be rejected (unless the first remote pushes their uuids to us beforehand.
* 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.