Re: svn commit: r1659013 - /subversion/trunk/subversion/libsvn_subr/dso.c
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
Received on 2015-02-12 19:02:31 CET
This is an archived mail posted to the Subversion Dev