As Peter mentioned, whatever attachment you included was wiped by the new tigris
Discussion Services. Could you resend with the attachment included inline?
Kouhei Sutou wrote:
> 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:
>>>> 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.
Received on 2008-12-30 23:25:19 CET