Ivan Zhakov wrote:
> On 7/27/07, Blair Zajac <email@example.com> wrote:
>> Ivan Zhakov wrote:
>>> On 7/26/07, Lieven Govaerts <firstname.lastname@example.org> wrote:
>>>> Well, the buildbot is pretty much useless when one buildslave is failing
>>>> all the time, so why don't we revert it for now so you can take your
>>>> time in fixing it?
>>> Problem is what we have to revert to fix builds. Because it started
>>> failing after I removed APR iconv dependency in commit r25650, but
>>> actual problem is in commit r25430. And my commit only shows problem
>>> in this commit, because made Subversion running faster :)
>>> Personally I don't like idea to revert my commit (I don't have idea
>>> about Blair's commit r25430).
>>> I think that possible way is temporary fix commit r25430 with
>>> including revision to transaction name.
>> I was under the impression that the failure in the tests discussed here was the
>> previously discussed issue with the lack of granularity of the clock under
>> Windows causing the txn_names_are_not_reused() test to fail, but after looking
>> at the logs, the two failures are not directly related to the clock:
>> FAIL: fs-test.exe 22: check old revisions
>> FAIL: fs-test.exe 28: test svn_fs_check_related
>> The new txn txn_names_are_not_reused() test succeeded in this run:
>> PASS: fs-test.exe 6: check that transaction names are not reused
> It's very interesting why this test isn't falling.
>> In this older run from r25511, after the txn commits, but before the iconv
>> change, tests #22 and #28 were passing:
>> There's a check I added in trivial_transaction() to validate that transaction
>> names contain only the ASCII characters, so the txn names is only ASCII.
>> How does removing iconv() change any of these things?
> Because Subversion became much faster using native Windows iconv.
> Tests will pass if you add breakpoints in these tests.
>> So the longer transaction names may be causing a problem, but why would removing
>> iconv support trigger that when the longer names did previously work? Backing
>> out the transaction changes will result in shorter transaction names and may
>> resolve this issue, but I'm thinking it may not be the real fix for the issue.
> Because fsfs doesn't like same transaction name only between revision.
> Before you commit it was impossible because transaction name had
> revision number.
Thanks, I was able to reproduce the problem on a Linux box by hardcoding the
apr_time_t() to a fixed time, then I saw the same test failures.
I'll put the revision in the txn for a short term fix till I get the txn
sequence code going, which should be this weekend.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Jul 27 03:00:59 2007