File not marked as 'M' when contents differ from repo

[Brendan Cully]

On Friday, 06 July 2007 at 12:08, Jim Hague wrote:
> On Thursday 05 July 2007 19:04, Matt Mackall wrote:
> > On Thu, Jul 05, 2007 at 05:58:16PM +0100, Jim Hague wrote:
> > > On Thursday 05 July 2007 17:08, Matt Mackall wrote:
> > > > Changes that don't change file time OR size OR mode are indeed not
> > > > detected.
> > >
> > > A quick look at the Subversion source suggests that they have the same
> > > problem. Or they would, were it not for the client calling
> > > svn_sleep_for_timestamps() (which sleeps to the next second tick + 0.1s
> > > for margin) after updating operations. Would you consider similar for hg?
> > > Bit hacky, I know.
> >
> > We could do that. But adding an average of a half a second to lots of
> > operations isn't a very friendly thing to do. You might not notice it
> > with SVN, but it would make my typical hg checkout up to 500% slower!
> 
> I don't follow here. To be sure, a half-second wait after each file update 
> during a checkout would be disastrous for performance, but a delay just 
> before the top level command exits? Or are people scripting lots of 
> checkouts/updates?
> 
> > The trick is to somehow make people who are doing automation like you
> > bear the penalty.
> 
> Now I know the problem, I can - and have - trivially worked around it. My 
> concern is only to save others falling into the same 'Aarrgh! Mercurial is 
> broken!' trap. A note in the documentation for, errr, hg status & hg commit 
> (?) would cover it. In fact, reading some of the chatter about 
> svn_sleep_for_timestamps() in the Subversion dev archives, it might be the 
> best approach; the sleep strategy is vulnerable anyway in the face of updates 
> from other processes or filesystems like FAT with >1s time resolution.

It's possible the inotify extension also solves this problem, though I
haven't tested this case yet.