[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Failed fs-test 65 (Was: Re: 1.9.5 up for signing/testing)

From: Evgeny Kotkov <evgeny.kotkov_at_visualsvn.com>
Date: Thu, 24 Nov 2016 13:36:06 +0300

Julian Foad <julianfoad_at_apache.org> writes:

> Just a drive-by thought: Should we report this to SQLite? Especially if by
> distilling the Subversion test we could write a SQLite self-test. I recall
> the SQLite team is big on thorough regression testing and so would likely
> want to know about this.
>
> (They then might have some influence with the Apple folks, or maybe not, but
> that's for them to deal with. It won't change our situation in the short
> time with regard to this particular version.)

I will take care of reporting this to SQLite authors.

This is quite an issue, as this bug caused by a custom patch makes SQLite
(a _derivative_ distributed under the name of SQLite, to be precise) unusable
in a typical reader-writer case. In the described case, the vanilla version
would have blocked in a retry loop allowing for the reader to finish its work
and notifying the API user via xBusyHandler(), but the patch causes it to
fail immediately, and this prevents concurrency.

Branko ─îibej <brane_at_apache.org> writes:

> The question is: what do we do about it? Complaining to Apple isn't
> likely to help. We could add a special case in the testcase for that
> version of SQLite on OSX, just to keep the test output in the green. But
> ... that seems like just a bit overdone.

To my mind, the test is of less concern, compared to the issue itself.

I would prefer to keep the test catching this bug for now, unless that
causes severe issues for maintainers. If that happens, we could add a
workaround.

Regards,
Evgeny Kotkov
Received on 2016-11-24 11:36:37 CET

This is an archived mail posted to the Subversion Dev mailing list.