[PATCH 3 of 3 stable] tests: document probable bug in test-largefiles-update.t

[Augie Fackler]

(+marmoute, martinvonz per irc chat, +kiilerix since you touched this area most recently)

> On Jan 30, 2017, at 6:54 PM, Augie Fackler <raf at durin42.com> wrote:
> 
> # HG changeset patch
> # User Augie Fackler <augie at google.com>
> # Date 1485817557 18000
> #      Mon Jan 30 18:05:57 2017 -0500
> # Branch stable
> # Node ID e1db62cfe471bc278697d771bc68589acbff9171
> # Parent  b4118549138f0872c218835d3ae10c9e70d867de
> tests: document probable bug in test-largefiles-update.t

This patch, not suitable for committing, demonstrates what I think is a weird largefiles bug. The test as written before this series fails (correctly, I think) 2% of the time (that is, it should fail 100% of the time, but due to a largefiles bug it does not). Patches 1 and 2 clarify the current situation and correct the defect in the test.

It seems like the defect (re-)exposed by patch 3 is slightly easier to observe under high load - on my workstation with -j10, I see it about 2% of the time. On gcc112 with -j150, I can reproduce it about 4% of the time. I sort of suspect a dirstate race, but I’m not familiar enough with our dirstate functionality to speak with any authority on that, or to even really have confidence on where I should be looking. I experimented with sleeps before and after this update call, but couldn’t make the problem better or worse, which I find baffling.

> 
> I don't really know what's going on here, so we should probably not
> commit this patch, but my conclusion based on the analysis in earlier
> patches is that the old use of --check was a defect. This also fails
> 2-3% of the time, as the code did before I moved the later call to
> update to --clean.
> 
> diff --git a/tests/test-largefiles-update.t b/tests/test-largefiles-update.t
> --- a/tests/test-largefiles-update.t
> +++ b/tests/test-largefiles-update.t
> @@ -705,6 +705,11 @@ the working context)
>   $ hg status -A --rev '.^1' large2
>   M large2
> 
> +Defect: this update *should* fail 100% of the time, because we already
> +*know* the dirstate is dirty. Experimentally, at the time of this
> +writing, the command only fails about 2% of the time.
> +  $ hg update --check --quiet 4
> +
> #else
> 
> Test that "hg status" against revisions other than parent ignores exec
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel