cmpilato@tigris.org writes:
> Author: cmpilato
> Date: 2002-08-01 15:46:49 -0500 (Thu, 01 Aug 2002)
> New Revision: 2845
>
> Modified:
> trunk/subversion/tests/libsvn_fs/fs-test.c
> Log:
> * subversion/tests/libsvn_fs/fs-test.c
> (commit_date): Add some (#if 0-d out) debugging code.
What was this all about? I'll tell you.
First, a primer on how this test works:
1. A = apr_time_now()
2. commit some changes
3. B = apr_time_now()
4. C = timestamp of the commit we just made.
5. if not (A <= B <= C) then error, else succeed.
Basically, I was seeing this test PASS or FAIL seemingly randomly.
That is, I would run:
% fs-test 23; fs-test 23; fs-test 23; fs-test 23
and would get a variable combination of PASSes and FAILs each time I
did so. My first thought was the svn_time_[to|from]_nts were losing
information, or that since apr_time_t is a 64-bit value, that I was
suffering a weird comparison operator resolution thing. However, I no
longer believe this is true.
I added a printf to svn_fs__dag_commit_txn () where we actually set
the datestamp for our commits, and the value returned from
apr_time_now() there was the same as the value after it had been
svn_time_to_nts'd (in that function) and back again (in the test). It
actually looks like apr_time_now() returns values that are *not*
necessarily ordered as one would expect. I suppose perhaps I could be
suffering some clock drift, but I don't see anything in
/var/log/* to indicate such a thing.
apr_time_now() on Unix just calls gettimeofdate() ... are there any
known problems that I should be aware of? My APR is a couple of weeks
out of date, but somehow that doesn't seem too important.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 2 01:10:11 2002