[PATCH 1 of 3] util: add fswatcher class

[Jason Harris]

On May 27, 2011, at 4:18 PM, Sune Foldager wrote:

> On 2011-05-27 07:40, Matt Mackall wrote:
>> On Fri, 2011-05-27 at 12:22 +0200, Sune Foldager wrote:
>>> >
>>> >Not at all sure about this mtime/ctime comparison business you're doing.
>>> >Not only is its safety suspect, several filesystems don't have the
>>> >concept of a ctime.
>>> 
>>> Well, the ctime is from time.time() to not really related to the file system.
>> 
>> Ahh, I see. Please, pick another variable name, it's impossible for a
>> Unix hacker to see mtime and ctime on the same line and not think
>> they're both referring to stat fields.
> 
> Alright.
> 
>>> Benoit told me this was the usual way to sidestep the sub-second problem.
>> 
>> Well, no, not exactly. We can't actually trust that system notion of
>> time is connected to the filesystem's notion of time (see network
>> filesystem). If all parties don't have a reliable NTP setup, it's quite
>> easy for causality to appear to be violated. Dirstate does:
>> 
>>       # use the modification time of the newly created temporary file as the
>>       # filesystem's notion of 'now'
>>       now = int(util.fstat(st).st_mtime)
>> 
>> For our watcher purposes, I'm not sure if there's a good way to do this
>> short of writing a temp file (to the same fs).
> 
> Somewhat annoying to have to do that, and where should we write to, etc.
> It requires more knowledge than the wather has currently.
> 
>>> Dirstate tracks and compares mtime and size and contents, that's a difference.
>>> Size alone is not enough, as an external tool could, in a very contrived
>>> scenario, go in and modify the repo.
>> 
>> Ok, but no one has ever suggested that size alone was enough. The idea
>> would be to force a reload if either mtime OR size (OR inode OR ctime,
>> etc.) changed.
> 
> But I'm not sure how you can't always cook up some pathological situation where
> it defeats anything we try here. Maybe we should, for the purpose of hgweb and
> hgwebdir, just accept that we can't catch all cases and then do one of
> two things:
> 
> - Do pretty well, e.g. maybe not start writing files to get a concept of
>  current time, unless we feel it's really needed. And maybe or maybe not
>  comparing sizes etc. We won't catch all cases, but some.
> - Document that it's peoples own responsibility to make sure the repo isn't
>  modified under their noses while the hold a repo instance, and then not
>  really check for it at all.
> 
> We would also exploit that for revlogs in particular, the size will almost
> always change if the repo is modified.
> 
> In either case, I agree with the .revalidate (or similar) "internal" approach,
> instead of the external watcher through .getwacther one.

So I have more or less followed this thread. And it looks interesting, but I have a
couple of questions.

For background:
In MacHg I use apples MonitorFSEvents to monitor the .hg directory to see if
changes have taken place there. I can ignore events in the cache directory
(and I have to patch hg to get around it writing files for exec checks, etc. If it
did this in the cache directory that would of course be better but see previous
threads about this...)

Will GUI writers change such functionality like I have here in the future after your
changes? Do you see this functionality somehow working around such things?
What is the long term goals of such functionality? Will it work in with Idan's stuff?

Thanks in advance!

Cheers,
  Jas