| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
repository when in indirect mode.
|
| | |
|
| |
|
|
|
| |
Needs work to deal with directory renames better; otherwise seems to
basically work.
|
| | |
|
| |
|
|
|
| |
It already applied the pruner when traversing directories, so .git is
excluded, but .gitignore was not. Now it is.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is handled differently for inotify, which can track modifications of
existing files, and kqueue, which cannot (TTBOMK). On the inotify side,
the TransferWatcher just waits for the file to be updated and reads the new
bytesComplete. On the kqueue side, the TransferPoller has to re-read the
file every update (currently 0.5 seconds, might need to increase that).
I did think about working around kqueue's limitations by somehow creating
a new file each time the size changed. But cleaning up all the files that
would result seemed difficult. And really, this is not a lot worse than
the TransferWatcher's behavior for downloads, which stats a file every 0.5
seconds. As long as the OS has decent file caching behavior..
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
The reason the DirWatcher had to wait for program termination was because
it used withINotify, so when it finished, its watcher threads were killed.
But since I have two DirWatcher threads now, that was not good, and could
perhaps explain the MVar problem I saw yesterday. In any case, fixed this
part of the code by making the DirWatcher return a handle that can be used
to stop it, and now the main Assistant thread is the only one calling
waitForTermination.
|
| | |
|
| | |
|
| | |
|
|
|
Kqueue code for dispatching events is not tested and probably doesn't
build.
|
Joey Hess
Joey Hess