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

Re: Status of TODO-1.6

From: Joe Swatosh <joe.swatosh_at_gmail.com>
Date: Sat, 27 Dec 2008 11:18:49 -0800

Hi kou,

On Fri, Dec 26, 2008 at 11:12 AM, Hyrum K. Wright
<hyrum_wright_at_mail.utexas.edu> wrote:
> Kouhei Sutou wrote:
>> Hi,
>> In <495271AD.8020401_at_mail.utexas.edu>
>> "Status of TODO-1.6" on Wed, 24 Dec 2008 11:30:21 -0600,
>> "Hyrum K. Wright" <hyrum_wright_at_mail.utexas.edu> wrote:
>>> * Test failures in Ruby bindings.
>>> These just look like they are the result of wrong expectations due to tree
>>> conflicts, but my understanding of ruby and the swig-rb bindings is so
>>> rudimentary as to remove all confidence in my ability to track it down. Kou,
>>> Joe, any suggestions?
>> The current test suits were all passed when they were
>> created. It means the current Subversion behavior is changed
>> since the time.
>> I don't know about tree conflicts. If the current actual
>> values are expected result, we should change the current
>> expected values. But I can't decide it...
> And I don't know enough about ruby and the test suite to determine exactly what
> the offending tests are testing. Either somebody with knowledge of both should
> comment, or perhaps you can give us an overview of what the tests are doing, and
> one of the tree conflicts people can comment on whether or not the new failures
> are expected.

I find myself getting lost in assert_merge() too. Could you either
add some messages to the assertions or perhaps split assert_merge into
some smaller named assertions to make it more clear?

I think its tough to test the bindings, as we have to assert
everything through side-effects, and some of the assertions seem like
they are testing merge itself instead of the _binding_ to the merge
function. (Does that make sense?)


Received on 2008-12-27 20:19:05 CET

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.