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

Ivan Zhakov <ivan_at_visualsvn.com> writes:

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

I just seen a failure and it revealed the current bug. I think the
tests explicitly clear the pools passed to RA/FS so they already follow
the rules and will not have a problem. A test would have to fail to
clear a pool for there to be a problem, and that would most likely be a
bug that should be fixed.

> 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?

svn_dso_initialize2 didn't exist until 1.6 and is only documented in
svn_dso.h. Do we expect people writing applications using the high
level API to read that? Do we expect people using old applications to
update them? Is it possible to call svn_dso_initialize2 when using the
bindings?

> Do we want to fight problems
> like we had with ra-test in future?

I haven't followed the details but I think the ra-test problem was
caused by failure to close a tunnel, nothing to do with initialization.

> 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

I'm still not seeing a gain, only the need to write another test.

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*