status of sharebox-fs?
joey at kitenet.net
Thu May 24 15:38:59 CEST 2012
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 828 bytes
Desc: Digital signature
More information about the vcs-home