On 12 February 2015 at 20:51, Philip Martin <philip.mar...@wandisco.com> wrote: > Ivan Zhakov <i...@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
