aboutsummaryrefslogtreecommitdiff
path: root/Command/Watch.hs
Commit message (Collapse)AuthorAge
...
* deletionGravatar Joey Hess2012-06-04
| | | | | | | | | | | | | | | | | | | | | When a new file is annexed, a deletion event occurs when it's moved away to be replaced by a symlink. Most of the time, there is no problimatic race, because the same thread runs the add event as the deletion event. So, once the symlink is in place, the deletion code won't run at all, due to existing checks that a deleted file is really gone. But there is a race at startup, as then the inotify thread is running at the same time as the main thread, which does the initial tree walking and annexing. It would be possible for the deletion inotify to run in a perfect race with the addition, and remove the newly added symlink from the git cache. To solve this race, added event serialization via a MVar. We putMVar before running each event, which blocks if an event is already running. And when an event finishes (or crashes!), we takeMVar to free the lock. Also, make rm -rf not spew warnings by passing --ignore-unmatch when deleting directories.
* suppress "recording state in git" message during addGravatar Joey Hess2012-06-04
|
* add handling of symlink addition eventsGravatar Joey Hess2012-06-04
| | | | | | | | And just like that, annexed files can be moved and copies around within the tree, and are automatically fixed to point to the content, and staged in git. Huzzah! Delete still remains TODO, with its troublesome race during add..
* handle directory deletionGravatar Joey Hess2012-06-04
| | | | | When a directory is deleted, or moved away, git rm -r it to stage the deletion.
* add events for symlink creation and directory removalGravatar Joey Hess2012-06-04
| | | | | | | | | | Improved the inotify code, so it will also notice directory removal and symlink creation. In the watch code, optimised away a stat of a file that's being added, that's done by Command.Add.start. This is the reason symlink creation is handled separately from file creation, since during initial tree walk at startup, a stat was already done, and can be reused.
* watch subcommandGravatar Joey Hess2012-04-12
So far this only handles auto-annexing new files that are created inside the repository while it's running. To make this really useful, it needs to at least: - notice deleted files and stage the deletion (tricky; there's a race with add..) - notice renamed files, auto-fix the symlink, and stage the new file location - periodically auto-commit staged changes - honor .gitignore, not adding files it excludes Also nice to have would be: - Somehow sync remotes, possibly using a push sync like dvcs-autosync does, so they are immediately updated. - Somehow get content that is unavilable. This is problimatic with inotify, since we only get an event once the user has tried (and failed) to read from the file. Perhaps instead, automatically copy content that is added out to remotes, with the goal of all repos eventually getting a copy, if df allows. - Drop files that have not been used lately, or meet some other criteria (as long as there's a copy elsewhere). - Perhaps automatically dropunused files that have been deleted, although I cannot see a way to do that, since by the time the inotify deletion event arrives, the file is deleted, and we cannot see what its symlink pointed to! Alternatievely, perhaps automatically do an expensive unused/dropunused cleanup process. Some of this probably needs the currently stateless threads to maintain a common state.