Quoting Nuutti Kotivuori <naked@iki.fi>:
> ,----[ #svn ]
> | 01:42 brane:#svn => time-test is failing on Windows
> | 01:42 brane:#svn => looks like an apr error again
> | 01:43 brane:#svn => in this case, gmt_offset doesn't get adjusted
> | for DST
> | 01:44 brane:#svn => gmt_offset should be the offset of the
> | timezone, not the local ime.
> | 01:45 brane:#svn => so the time test (using the old format, which
> | is in local time) is off by 1 hour
> `----
>
> Yes, I left that old format there intentionally to be in local time
> just to catch regression of that timezone handling.
Oh, that's fine. I even looked into having _two_ tests, one with DST on and one
without.
I only meant to ask if time-test was failing on Unix or not, to confirm my
theory that it was an APR error.
> But, if only the old format time test fails - and the time read-write
> invariant works - it's not so bad. The timestamp generated after my
> patch (rev 2012) are not in local time anymore - and apparently apr
> seems to work fine for timestamps that are not in local time.
APR is only broken on Windows. And if we can't convert correctly between old and
new format timestamps (even if it's just a question of being off by one hour),
then we'll have weird timestamps in the working copies.
Anyway, I didn't mean to imply that _you_ had done something wrong. I'm just a
bit sad because I'd fixed that very code in APR before, and somebody went and
hosed it again. Maybe the APR tests don't tickle this particular problem.
I may look into it once I finish the delta combiner, but I don't have time now.
Volunteers welcome. :-)
> So, it hasn't affected us for a while now (except for possible user
> display in some places) - and the old timestamps are already broken -
> so nothing else breaks if that is fixed.
>
> ...
>
> Perhaps there should be a troubleshooting guide which would list
> possible places to look when a regression test fails?
>
> time-test, #1) APR is borked again.
>
> time-test, #2) APR is borked again.
No, if a test that used to succeed starts failing, the reason should be analysed
every time. It's dangerous to rely on results of previous analyses too much.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 4 13:06:48 2002