Robert Zeh wrote: > On Sun, Feb 10, 2013 at 9:21 PM, Duy Nguyen <pclo...@gmail.com> wrote: >> On Mon, Feb 11, 2013 at 2:03 AM, Robert Zeh <robert.allan....@gmail.com> >> wrote: >>> On Sat, Feb 9, 2013 at 1:35 PM, Junio C Hamano <gits...@pobox.com> wrote: >>>> Ramkumar Ramachandra <artag...@gmail.com> writes: >>>> >>>>> This is much better than Junio's suggestion to study possible >>>>> implementations on all platforms and designing a generic daemon/ >>>>> communication channel. That's no weekend project. >>>> >>>> It appears that you misunderstood what I wrote. That was not "here >>>> is a design; I want it in my system. Go implemment it". >>>> >>>> It was "If somebody wants to discuss it but does not know where to >>>> begin, doing a small experiment like this and reporting how well it >>>> worked here may be one way to do so.", nothing more. >>> >>> What if instead of communicating over a socket, the daemon >>> dumped a file containing all of the lstat information after git >>> wrote a file? By definition the daemon should know about file writes. >>> >>> There would be no network communication, which I think would make >>> things more secure. It would simplify the rendezvous by insisting on >>> well known locations in $GIT_DIR. >> >> We need some sort of interactive communication to the daemon anyway, >> to validate that the information is uptodate. Assume that a user makes >> some changes to his worktree before starting the daemon, git needs to >> know that what the daemon provides does not represent a complete >> file-change picture and it better refreshes the index the old way >> once, then trust the daemon. >> >> I think we could solve that by storing a "session id", provided by the >> daemon, in .git/index. If the session id is not present (or does not >> match what the current daemon gives), refresh the old way. After >> refreshing, it may ask the daemon for new session id and store it. >> Next time if the session id is still valid, trust the daemon's data. >> This session id should be different every time the daemon restarts for >> this to work. > > I think we could do this without interactive communication, > if we did the following: > 1) The Daemon waits to see $GIT_DIR/lstat_request, and atomically > writes out $GIT_DIR/lstat_cache. By atomically I mean that it writes > things out to a temporary file, and then does a rename. > > 2) The client erases $GIT_DIR/lstat_cache, and writes > $GIT_DIR/lstat_request > > I think this is better than socket based communication because there > are fewer places to check > for failures.
My main problem with file-based solutions is this: how will the daemon accumulate inotify change events over time, and report it in a batch to a git application that is spawned? Will it append to the .git/inotify_changes file everytime there's a change? Wouldn't you prefer to accumulate the events in-memory and report it over a socket upon explicit request, to minimize IO? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
