Random test_hammer_hashcache failure

It probably is timing dependent, it's an old crusty test.

--
Martin <http://launchpad.net/~mbp/>

On Wed, 2009-09-23 at 07:16 +0000, Martin Pool wrote:
> It probably is timing dependent, it's an old crusty test.

It could alternatively be a latent bug :(

-Rob

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Collins wrote:
> On Wed, 2009-09-23 at 07:16 +0000, Martin Pool wrote:
>> It probably is timing dependent, it's an old crusty test.
>
> It could alternatively be a latent bug :(
>
> -Rob
>

So the point of hammer_hashcache (as I recall) is to spin on updating a
file and checking the hashcache to make sure it really does wait an
appropriate amount of time to make sure that content has changed.

It isn't a very deterministic test, and it is a fairly long running one,
but I can agree with Robert that if there is a problem it may, in fact,
be genuine, and not just a testing artifact.

On the flip side, I don't think we use 'hashcache' since WT3, so it
isn't being exercised in day-to-day. (We've advised upgrading to
- --dirstate + since bzr 0.15.)

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkq6I/AACgkQJdeBCYSNAAN0GACeImen35KoUn0LUCFaSiU6z6jY
LsoAmwcbNB/KAtOCUAXn2kl3sTBinWzU
=6g47
-----END PGP SIGNATURE-----

New occurrence on karmic:
  http://babune.ladeuil.net:26862/builders/karmic/builds/82/steps/Non-regression tests/logs/stdio
and gentoo:
  http://babune.ladeuil.net:26862/builders/gentoo/builds/36/steps/Non-regression tests/logs/stdio

While I still can't reproduce it, I'm more and more thinking about a VM related cause.