aboutsummaryrefslogtreecommitdiff
path: root/Assistant/Threads/ConfigMonitor.hs
Commit message (Collapse)AuthorAge
* improve data typeGravatar Joey Hess2016-01-01
|
* update my email address and homepage urlGravatar Joey Hess2015-01-21
|
* Added required content configuration.Gravatar Joey Hess2014-03-29
| | | | | | | This includes checking when dropping files that any required content configuration is satisfied. However, it does not yet include an active check on the required content; the location log is trusted when checking the required content expression.
* reload preferred content when group preferred content log changesGravatar Joey Hess2014-03-29
|
* reorganize numcopies code (no behavior changes)Gravatar Joey Hess2014-01-21
| | | | | | | Move stuff into Logs.NumCopies. Add a NumCopies newtype. Better names for various serialization classes that are specific to one thing or another.
* global numcopies settingGravatar Joey Hess2014-01-20
| | | | | | | | | | | | | | | | | | | | | | | * numcopies: New command, sets global numcopies value that is seen by all clones of a repository. * The annex.numcopies git config setting is deprecated. Once the numcopies command is used to set the global number of copies, any annex.numcopies git configs will be ignored. * assistant: Make the prefs page set the global numcopies. This global numcopies setting is needed to let preferred content expressions operate on numcopies. It's also convenient, because typically if you want git-annex to preserve N copies of files in a repo, you want it to do that no matter which repo it's running in. Making it global avoids needing to warn the user about gotchas involving inconsistent annex.numcopies settings. (See changes to doc/numcopies.mdwn.) Added a new variety of git-annex branch log file, that holds only 1 value. Will probably be useful for other stuff later. This commit was sponsored by Nicolas Pouillard.
* update for LsTree type changeGravatar Joey Hess2013-10-17
| | | | in the config monitor, we want files relative to the top of the working directory
* half way complete cronner thread to run scheduled activitiesGravatar Joey Hess2013-10-08
|
* hlintGravatar Joey Hess2013-10-02
|
* webapp: Now allows restarting any threads that crash.Gravatar Joey Hess2013-01-26
|
* use async to track and manage threadsGravatar Joey Hess2013-01-26
|
* automatic repolist updatingGravatar Joey Hess2012-11-13
|
* don't delay at startupGravatar Joey Hess2012-10-30
| | | | | | Still wait 1 minute after a change before waiting on the next change, but don't wait at the start, when we might get a pull that contains config changes right away.
* 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 Commits and liftedGravatar Joey Hess2012-10-29
|
* split BranchChange and liftedGravatar Joey Hess2012-10-29
|
* converted 6 more threadsGravatar Joey Hess2012-10-29
|
* 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.
* 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.
* push out config changesGravatar Joey Hess2012-10-21
|
* add ConfigMonitor threadGravatar Joey Hess2012-10-20
Monitors git-annex branch for changes, which are noticed by the Merger thread whenever the branch ref is changed (either due to an incoming push, or a local change), and refreshes cached config values for modified config files. Rate limited to run no more often than once per minute. This is important because frequent git-annex branch changes happen when files are being added, or transferred, etc. A primary use case is that, when preferred content changes are made, and get pushed to remotes, the remotes start honoring those settings. Other use cases include propigating repository description and trust changes to remotes, and learning when a remote has added a new special remote, so the webapp can present the GUI to enable that special remote locally. Also added a uuid.log cache. All other config files already had caches.