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>
>>> 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
> 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