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
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
Received on 2008-12-28 06:10:26 CET