summaryrefslogtreecommitdiff
path: root/Assistant/Commits.hs
Commit message (Collapse)AuthorAge
* add exporter thread to assistantGravatar Joey Hess2017-09-20
| | | | | | | | | | | | | | | | | | | | | | | This is similar to the pusher thread, but a separate thread because git pushes can be done in parallel with exports, and updating a big export should not prevent other git pushes going out in the meantime. The exportThread only runs at most every 30 seconds, since updating an export is more expensive than pushing. This may need to be tuned. Added a separate channel for export commits; the committer records a commit in that channel. Also, reconnectRemotes records a dummy commit, to make the exporter thread wake up and make sure all exports are up-to-date. So, connecting a drive with a directory special remote export will immediately update it, and getting online will automatically update S3 and WebDAV exports. The transfer queue is not involved in exports. Instead, failed exports are retried much like failed pushes. This commit was sponsored by Ewen McNeill.
* update my email address and homepage urlGravatar Joey Hess2015-01-21
|
* remove last use of TSetGravatar Joey Hess2013-04-24
|
* assistant: generate better commits for renamesGravatar Joey Hess2013-03-10
|
* split Commits and liftedGravatar Joey Hess2012-10-29
|
* ensure that git-annex branch is pushed after a successful transferGravatar Joey Hess2012-10-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | I now have this topology working: assistant ---> {bare repo, special remote} <--- assistant And, I think, also this one: +----------- bare repo --------+ v v assistant ---> special remote <--- assistant While before with assistant <---> assistant connections, both sides got location info updated after a transfer, in this topology, the bare repo *might* get its location info updated, but the other assistant has no way to know that it did. And a special remote doesn't record location info, so transfers to it won't propigate out location log changes at all. So, for these to work, after a transfer succeeds, the git-annex branch needs to be pushed. This is done by recording a synthetic commit has occurred, which lets the pusher handle pushing out the change (which will include actually committing any still journalled changes to the git-annex branch). Of course, this means rather a lot more syncing action than happened before. At least the pusher bundles together very close together pushes, somewhat. Currently it just waits 2 seconds between each push.
* licenseGravatar Joey Hess2012-06-23
|
* stub syncer thread and commit channelGravatar Joey Hess2012-06-22