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

Re: svn commit: r1659013 - /subversion/trunk/subversion/libsvn_subr/dso.c

From: Ivan Zhakov <ivan_at_visualsvn.com>
Date: Thu, 12 Feb 2015 21:00:35 +0300

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

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.