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/
-----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----- enigmail. mozdev. org/
6I/AACgkQJdeBCY SNAAN0GACeImen3 5KoUn0LUCFaSiU6 z6jY KAtOCUAXn2kl3sT BinWzU
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAkq
LsoAmwcbNB/
=6g47
-----END PGP SIGNATURE-----