Missed Change on commit

[Robin Farine]

On Thursday February 15 2007 21:26, Matt Mackall wrote:
> On Thu, Feb 15, 2007 at 09:20:47PM +0100, Robin Farine wrote:
> > On Thursday February 15 2007 20:08, Matt Mackall wrote:
> > > On Thu, Feb 15, 2007 at 10:47:37AM -0700, Russell Suter wrote:
> > > > Hi All,
> > > >
> > > > I have an example where a commit is missing a change.  I've
> > > > attached a script and the output that (for me) always
> > > > breaks. Specifically, in the output the commit didn't
> > > > pickup the branch 2 version 1 change:
> > >
> > > Mercurial can miss a change if the change happens so quickly
> > > that it doesn't change the timestamp or the size that we
> > > recorded for the file.
> > >
> > > Possible fixes:
> > >
> > > a) wait until the next second after recording dirstate
> > >    this will catch any changes made after update but will
> > > penalize everyone by a half second per add/merge/update...
> >
> > Tried this, it becomes extremely painful to run the tests.
> >
> > How about verifying each file with an mtime equal to the mtime
> > of the dirstate file itself? This would catch files changed in
> > the same second as the dirstate has been updated. Something
> > like this:
>
> I meant to include that in my list. What sort of time delta do
> tests show?

make tests in mercurial without the dirstate patch:
real    4m38.635s
user    2m49.643s
sys     0m51.327s

and with the patch:
real    4m38.353s
user    2m50.339s
sys     0m51.979s

hg status in a recently updated linux-2.6 tree (with the dirstate 
patch):
real    0m1.703s
user    0m1.464s
sys     0m0.236s

hg status in a clone --pull of this linux tree:
real    0m1.671s
user    0m1.444s
sys     0m0.228s

and hg status in this tree without the dirstate patch:

real    0m1.652s
user    0m1.424s
sys     0m0.220s

So no difference. But of course the difference might be noticeable 
with a cold cache or on a faster machine where the clone operation 
would result in more files in the same second as the dirstate.

> Note that if it takes, say, 60 seconds to check out a tree with
> 20k files, the last 300 or so will be in that last second. On
> average, half of those 300 will be in the last partial second. So
> we'll take a hit quite often.

Ah yes, right.

When such files are detected, perhaps we can make the dirstate 1s 
younger and all the problematic files that actually changed 2s 
younger so the next pass will not have to compare these files? But 
in my case, it does not look like it is worth it anyway.

Robin