[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.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.