Ivan Zhakov <i...@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*
