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

Re: svn commit: r1028104 - /subversion/branches/performance/subversion/tests/libsvn_subr/string -test.c

From: Stefan Fuhrmann <stefanfuhrmann_at_alice-dsl.de>
Date: Sat, 30 Oct 2010 18:27:40 +0200

On 28.10.2010 17:06, Julian Foad wrote:
> On Thu, 2010-10-28 at 15:52 +0100, Julian Foad wrote:
>> Daniel Shahaf wrote:
>>> +1
>>>
>>> stefan2_at_apache.org wrote on Wed, Oct 27, 2010 at 21:23:35 -0000:
>>>> URL: http://svn.apache.org/viewvc?rev=1028104&view=rev
>>>> Log:
>>>> Adapt string unit test to recent behavioral changes.
>>>>
>>>> * subversion/tests/libsvn_subr/string-test.c
>>>> (test10): relax tests on string capacity
>> Sure, +1 to your changes here.
>>
>> But what are the rest of these crazy "requirements" in this old test?
>>
>> [...]
>>>> /* Test that:
>>>> - * - The initial block was just the right fit.
>>>> + * - The initial block was at least the right fit.
>>>> + * - The initial block was not excessively large.
>> Yup, great.
>>
>>>> * - The block more than doubled (because second string so long).
>> This works, for typical alignments and this test data. But "more than
>> doubled" is not necessary. A sensible test would be that it "at least
>> doubled".
>>
>>>> * - The block grew by a power of 2.
>> Why would we care whether it grew by a power of 2? Any growth by at
>> least a factor of 2 is efficient and satisfactory.
>>
>>>> */
>>>> - if ((len_1 == (block_len_1 - 1))
>>>> -&& ((block_len_2 / block_len_1)> 2)
>>>> -&& (((block_len_2 / block_len_1) % 2) == 0))
>>>> + if ((len_1<= (block_len_1 - 1))
>>>> +&& ((block_len_1 - len_1)<= APR_ALIGN_DEFAULT(1))
>>>> +&& ((block_len_2 / block_len_1)> 2)
>>>> +&& (((block_len_2 / block_len_1) % 2) == 0))
>> That last line does NOT check that the block length grew by a power of
>> two anyway. It checks it grew by a factor of [2 to 2.9999] or [4 to
>> 4.9999] or [6 to 6.9999] or ...
>>
>> Let's axe that last line.
> Done in r1028340.
>
> Apologies in advance for the merge conflict this will cause when merging
> your change to trunk.
No worries.

BTW, is there any policy on documenting merge conflict
so that people can have a second look at it if they care?

-- Stefan^2.
Received on 2010-10-30 18:28:41 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.