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

Re: svn commit: r1493097 - /subversion/trunk/subversion/tests/cmdline/svntest/main.py

From: Ivan Zhakov <ivan_at_visualsvn.com>
Date: Wed, 19 Jun 2013 17:45:02 +0400

On Wed, Jun 19, 2013 at 5:04 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Wed, Jun 19, 2013 at 03:50:01PM +0400, Ivan Zhakov wrote:
>> On Fri, Jun 14, 2013 at 6:40 PM, <stsp_at_apache.org> wrote:
>> > Author: stsp
>> > Date: Fri Jun 14 14:40:17 2013
>> > New Revision: 1493097
>> >
>> > URL: http://svn.apache.org/r1493097
>> > Log:
>> > Run tests with an exclusive lock on working copies. This should reduce test
>> > run time and also ensures that exclusive locking mode is tested.
>> >
>> > I've run ra_local and ra_serf tests with this change and got no failures.
>> > In any case, if there were any test failures with exlusive locking mode
>> > enabled, they'd most likely expose bugs in the test suite or Subversion itself.
>> >
>> I don't like this change actually:
>> 1. Running tests in different configuration than regular users are
>> using bad practice
>
> I did think about this before making the change.
>
> Your argument can be turned around. If we never test the exclusive
> locking mode, how can we be sure that it works?
>
Just make it optional and someone who interested in this particular
configuration will use it for testing. Or configure dedicated buildbot
for that.

> And consider that, if a test passes with exclusive locking, it very
> likely passes with less restrictive locking. But the reverse is not true!
> Tests could fail in exclusive locking mode due to bugs in the tests
> or the code, and we would never see those failures until now.
>
No. It's just two different configuration and you cannot say that if
it pass in one configuration it also doesn't have problems with
another.

>> 2. It also seems to broke svn benchmarks posted every week, because
>> now we get totally different numbers for operations.
>
> That's unfortunate. But what about things like server-side caching?
> Don't improvements in such areas have similar effects? I think having
> better test coverage and test speed is more important than keeping
> the benchmark results consistent over time.
Server-side caching is default configuration. I'm just asking your
keep running test suite in default configuration, which most (at least
80%) users are using.

>
>> Could you please make option to running test suite with exclusive
>> locking mode and leave it 'off' by default. Thanks!
>
> I could do that, yes. But it multiples the number of test configurations
> yet again, which I don't like. If we do this, I can switch my buildbot
> to use exclusive locks. And if the buildbot fails some day or we stop
> maintaining the bot, test coverage will get worse again because nobody
> tests exclusive mode anymore. So I'd rather have the default be 'on'.
Multiple tests configurations is great because every person/build can
right tests for different configuration. But default should be the
same as default Subversion configuration.

-- 
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
Received on 2013-06-19 15:45:54 CEST

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.