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

Re: APR hash order ruby test failure

From: Joe Swatosh <joe.swatosh_at_gmail.com>
Date: Wed, 28 Mar 2012 21:44:25 -0700

On Wed, Mar 28, 2012 at 5:44 AM, Philip Martin
<philip.martin_at_wandisco.com> wrote:
> Hyrum K Wright <hyrum.wright_at_wandisco.com> writes:
>
>> On Wed, Mar 28, 2012 at 4:30 AM, Philip Martin
>>>
>>> We fix these by converting the arrays to sets so that the order is
>>> irrelevant.  The open question is whether we do this solely within the
>>> testsuite, changing both sides of the comparison, or whether we change
>>> the bindings to return a set and adjust the testsuite to match.
>>
>> I think that depends on the compatibility guarantees of the bindings.
>> Making them a set feels more correct from a semantic perspective, but
>> I don't know if it will break existing consumers.
>
> Indeed; Daniel and I discusssed it on IRC.  We don't really know what
> guarantees apply.  We don't know who consumes the Ruby bindings, google
> doesn't show much so perhaps it's people writing private stuff.  Some
> consumers may not even notice an array to set change and would continue
> to operate.
>
> --
> uberSVN: Apache Subversion Made Easy
> http://www.uberSVN.com

Sorry I haven't had any time to devote to this. I changed something,
now my tests are failing for revisions that used to pass..... I'm not
sure what the compatibility guarantees are. In the past, working with
kou, we basically tried to keep everything backward compatible.

From that perspective, it seems to me that the best approach is to use
the Set in the test, but not in the bindings themselves. Also the
current APIs don't provide order guarantees (obviously), but if they
started to guarantee order in the future, the Set may be a bad choice
in the interface. I haven't had a chance to even look at this, so take
the above with a grain of salt.

--
Joe
Received on 2012-03-29 06:45:01 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.