On 12 February 2015 at 20:51, Philip Martin <philip.martin_at_wandisco.com> wrote:
> Ivan Zhakov <ivan_at_visualsvn.com> writes:
>
>> Sorry, but I've lost what problem we're trying to solve now? Why just
>> do not add call to svn_dso_initialize2() (or svn_cmdline_init()) in
>> our testsuite and move forward?
>
> What do we gain? We already have programs that that call
> svn_dso_initialize2: svn, svnserve, ... If we make all our test
> programs do the same we lose the ability to test our on-the-fly
> initialization, the very thing that revealed the current problem.
>
As far I understand out testsuite still may fail in some rare
circumstances with --parallel option, until we add
svn_dso_initialize2(). It's bad when tests are failing sometimes.
We already documented that applications *should* call
svn_dso_initialize2() on startup. Why test some unrecommended usage of
our API that I known to lead problems? Do we want to fight problems
like we had with ra-test in future? Testing on-the-fly
initialization() is a good goal, but not as expense of usual
development IMO. We may add special 'on-the-fly-initialization' test
program if you think that it's important to test this behavior. Just
my $0.02
--
Ivan Zhakov
Received on 2015-02-12 19:02:31 CET