On Feb 10, 2013, at 1:26 PM, Martin Fick <mf...@codeaurora.org> wrote:
> On Sunday, February 10, 2013 12:03:00 pm Robert Zeh 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.
> But git doesn't, how will it know when the file is written?
> Will it use inotify, or poll (kind of defeats the point)?
I was thinking it would loop on calls to stat for the file with a timeout; this
is no different than what we would want to do over a socket in that we would
need timeouts for network reads. But we would only be calling stat on one
file, instead of the entire repo.
I think we can set things up so the file read is atomic, which means we can
ignore the case of a daemon crashing midway through a conversation.
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