# HG changeset patch # User Martin von Zweigbergk # Date 2019-01-11 00:36:55 # Node ID 3227923979a11f6889f0c698c37c08f31e40994f # Parent 69804c040a0414588c7fd37346aeae0c1d69c126 tests: de-flake test-narrow-share.t by making dirstate predictable test-narrow-share.t was sometimes (~0.5% on my machine) failing like this: @@ -61,7 +61,7 @@ A d3/g $ hg -R main debugdirstate --no-dates n 644 2 set d1/f - n 644 2 unset d3/f + n 644 2 set d3/f a 0 -1 unset d3/g n 644 2 set d5/f n 644 2 set d7/f The timestamp for d3/f would get set if it was determined at some point that it was clean. That check is usually done when the user runs `hg st`. We don't do that before the failure in the test case, but it happens at the end of the `hg clone` call. So if the file system's time happens to roll over after the clone's working copy has been written, but before its (final) dirstate has been written, we can end up with a set timestamp there. This patch makes it consistent by sleeping for 2 seconds so the timestamp gets reliably set. Differential Revision: https://phab.mercurial-scm.org/D5568 diff --git a/tests/test-narrow-share.t b/tests/test-narrow-share.t --- a/tests/test-narrow-share.t +++ b/tests/test-narrow-share.t @@ -44,6 +44,14 @@ Narrow the share and check that the main repo's working copy gets updated +# Make sure the files that are supposed to be known-clean get their timestamps set in the dirstate + $ sleep 2 + $ hg -R main st + $ hg -R main debugdirstate --no-dates + n 644 2 set d1/f + n 644 2 set d3/f + n 644 2 set d5/f + n 644 2 set d7/f # Make d3/f dirty $ echo x >> main/d3/f $ echo y >> main/d3/g @@ -58,7 +66,7 @@ Narrow the share and check that the main A d3/g $ hg -R main debugdirstate --no-dates n 644 2 set d1/f - n 644 2 unset d3/f + n 644 2 set d3/f a 0 -1 unset d3/g n 644 2 set d5/f n 644 2 set d7/f