[PATCH 3 of 4] test-dirstate-race: ensure that a isn't in the lookup set at the end
Martin von Zweigbergk
martinvonz at google.com
Mon Jun 12 09:34:40 EDT 2017
If Sid did want an unset timestamp in the dirstate (it sounded like he
didn't really need it), he could also use debugrebuilddirstate, right? I
think that always leaves the timestamp unset.
On Jun 12, 2017 4:52 AM, "FUJIWARA Katsunori" <foozy at lares.dti.ne.jp> wrote:
At Mon, 12 Jun 2017 20:12:39 +0900,
FUJIWARA Katsunori wrote:
>
> At Mon, 12 Jun 2017 19:31:55 +0900,
> FUJIWARA Katsunori wrote:
> >
> > At Mon, 12 Jun 2017 19:04:28 +0900,
> > FUJIWARA Katsunori wrote:
> > >
> > > At Sun, 11 Jun 2017 22:24:20 -0700,
> > > Siddharth Agarwal wrote:
> > > >
> > > > On 6/11/17 10:21 PM, Martin von Zweigbergk via Mercurial-devel
wrote:
> > > > > Doesn't look like it's guaranteed to be unset. Running
"run-tests.py
> > > > > -j50 --runs-per-test=50 test-dirstate-race.t" seems to confirm
that (2
> > > > > of 5 failed for me). How do you rely on it in an upcoming patch?
> > > >
> > > >
> > > > Interesting, I'm not seeing that on my Linux box. Could you drop
this
> > > > for now? I think I can work around this problem.
> > >
> > > Unfortunately, this can occur, if mtime of "a" is N, and _getfsnow()
> > > returns N+1 or more (= "a" is written out at almost N+1 but N in
> > > "int").
> > >
> > > IMHO, "hg update" with --config debug.dirstate.delaywrite=2 should
> > > avoid this problem.
> >
> > Oops, sorry, this is incorrect, because this is the way to ENSURE
> > mtime in dirstate :-<
> >
> > IMHO, additional "touch -t YYYYmmddHHMM 'a'" and "hg status" with
> > tests/fakedirstatewritetime.py in previous $TESTTMP/dirstaterace.sh
> > can ensure "unset"-ness of mtime in dirstate in this
> > test-dirstate-race.t case.
> >
>
> FYI, changes below can always reproduce Martin's situation, in which
> files are changed at N, but dirstate is written out N+1 or later in
> sec.
>
> And uncommenting two lines after "enabling below ..." line should fix
> this issue.
>
> After confirming that fakedirstatewritetime.py works as expected,
> "--config debug.dirstate.delaywrite=2" can be omitted for efficiency :-)
>
> ========================================
> diff --git a/tests/test-dirstate-race.t b/tests/test-dirstate-race.t
> --- a/tests/test-dirstate-race.t
> +++ b/tests/test-dirstate-race.t
> @@ -134,8 +134,21 @@ condition (see issue5584 for detail).
> > # To reproduce similar situation easily and certainly, #2 and #3
> > # are swapped. "hg cat" below ensures #2 on "hg status" side.
> >
> - > hg update -q -C 0
> + > # "--config debug.dirstate.delaywrite=2" emulates that files are
> + > # changed at N, but dirstate is written out N+1 or later in sec
> + > hg update -q -C 0 --config debug.dirstate.delaywrite=2
> > hg cat -r 1 b > b
> + >
> + > #### enabling below can ensure that mtime of 'a' in dirstate is unset
> + > # touch -t 200001010000 a
> + > # hg status --config extensions.fakedirstatewritetime=$
TESTDIR/fakedirstatewritetime.py
> + > EOF
> +
> + $ cat >> .hg/hgrc <<EOF
> + > [fakedirstatewritetime]
> + > # emulate invoking dirstate.write() via repo.status()
> + > # at 2000-01-01 00:00
> + > fakenow = 200001010000
> > EOF
>
> "hg status" below should excludes "e", of which exec flag is set, for
> ========================================
Sorry for consecutive posting, but one more :-)
"hg status" with fakedirstatewritetime above causes "? b" output
before "skip updating dirstate: identity mismatch" message of outer
"hg status".
To avoid this meaningless output:
- add "-m" option or so to "hg status" with fakedirstatewritetime, or
- move "hg cat -r 1 b > b" after "hg status" with fakedirstatewritetime
(the former seems reasonable, in order to put commands together by
each purpose)
>
> > >
> > > > _______________________________________________
> > > > Mercurial-devel mailing list
> > > > Mercurial-devel at mercurial-scm.org
> > > > https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
> > >
> > > --
> > > ----------------------------------------------------------------------
> > > [FUJIWARA Katsunori] foozy at lares.dti.ne.jp
> > > _______________________________________________
> > > Mercurial-devel mailing list
> > > Mercurial-devel at mercurial-scm.org
> > > https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
> >
> > --
> > ----------------------------------------------------------------------
> > [FUJIWARA Katsunori] foozy at lares.dti.ne.jp
> >
>
> --
> ----------------------------------------------------------------------
> [FUJIWARA Katsunori] foozy at lares.dti.ne.jp
>
--
----------------------------------------------------------------------
[FUJIWARA Katsunori] foozy at lares.dti.ne.jp
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel at mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20170612/f79edcb7/attachment.html>
More information about the Mercurial-devel
mailing list