Re: Status of TODO-1.6

Kou,
As Peter mentioned, whatever attachment you included was wiped by the new tigris
Discussion Services. Could you resend with the attachment included inline?

-Hyrum

Kouhei Sutou wrote:
> Hi,
>
> In <ae6cb1100812271118u36c2ae9aj7b773b770bff303b_at_mail.gmail.com>
> "Re: Status of TODO-1.6" on Sat, 27 Dec 2008 11:18:49 -0800,
> Joe Swatosh <joe.swatosh_at_gmail.com> wrote:
>
>> 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?
>
> OK. What about the attached patch?
>
>> 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?)
>
> I think that the bindings can do all things that can be done
> with the Subversion C library. It's the reason why the Ruby
> bindings' test scenario is written based on the original
> Subversion feature's work. (e.g. merging)
>
> We can write the Ruby bindings' tests more roughly like
> other bindings. If we do so, we can maintain the Ruby
> bindings' tests more easily because the Ruby bindings' tests
> have less failures than now in the feature Subversion
> development. But I think that it may miss some bugs caused
> by the Subversion C library's changes. I think we have tests
> for detecting those bugs. (I remember that there were some
> SEGV bugs detected by the Ruby bindings' tests.)
>
> We have a tradeoff between easy maintenance and bug
> detectability. The latter is more important for me. (Because
> the current Ruby bindings' tests are tough.) But if the
> Subversion project or Joe selects the former, I'll follow
> the selection. The Ruby bindings aren't only for my project.
>
>
> Thanks,
> --
> kou
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=994180
>

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=996360