René Mayrhofer wrote: > > No, I punted on it. The inotify managed directory will behave > > differently/annoyingly when the user tries to modify files. This > > certianly doesn't perfectly cover every use case, but I feel it's an > > ok tradeoff, you can get used to that behavior. > There is some event coalescing code towards making file changes less > annoying in my current dvcs-autosync devel branch (on gitorious). > However, due to time constraints, I haven't yet gotten around to > implementing the corner cases that I wanted to for about 4 months.... > (Hint: unpacking a big tar file is something I don't want to see being > split into as many separate git commits as there are files, while I > would like a commit for every change to a document I am currently > editing - there's a trade-off in there when only passively monitoring > the changes via inotify.) > > If you'd like to talk about a few of the issues, I hope to find time to > do so (life will remain crazy for the next about 4 months). I've been > playing with the inotify-triggered commits idea for a while and already > bumped my nose at a few ugly cases that I might assist you in avoiding.
Would absolutely be appreciated. I have been planning on only committing when it syncs, or something like that, rather than on every new file. It seems to make sense to commit every time an existing file is changed, but bundle new files. As far as I can tell, inotify has an unavoidable race when a new directory is created -- before the program gets a chance to add a watch on the directory, files or directories can be added to it, with no inotify events generated for them. There is a workaround, manually recursively scan each new directory after adding the watch. If you have other gotchas like these, do tell.. -- see shy jo
Description: Digital signature
_______________________________________________ vcs-home mailing list email@example.com http://lists.madduck.net/listinfo/vcs-home