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

Re: Ruby bindings test failures on Windows

From: Joe Swatosh <joe.swatosh_at_gmail.com>
Date: 2007-05-09 06:54:25 CEST


On 5/8/07, Kouhei Sutou <kou@cozmixng.org> wrote:
> Hi,
> 2007/5/9, Joe Swatosh <joe.swatosh@gmail.com>:
> > Are you sure that's the right patch? It modified and deleted many
> > tests
> Oh, sorry... I sent a wrong patch...
> I'll attach a correct patch.
> > I knew my patch affected the other simple provider test, what
> > other tests did it impact?
> It's the problem.
> I think that we should not modify existing tests if there is no
> reason. It seems that the other simple provider tests has no
> problem. I want you to modify only
> test_windows_simple_provider. If there is other problem,
> we should fix that in another revision.

Okay. Your patch wouldn't pass the tests because
assert_simple_provider() can't
be run more than once in a test (it tries to add the file to the repository
every time). The attached patch passes the tests. I made
test_simple_windows_provider() into three different tests. To do this I had to
modify the block in the third test somewhat.

I'm not crazy for assert_simple_provider(). To me it is confusing to be
creating invoking the ctx.add_simple_provider() so many times during a test of
add_windows_simple provider() or for that matter add_keychain_simple_provider().

I didn't want to start it before asking, but perhaps it would be a good idea to
make the assert_simple_provider() more focused and use it more like the 3rd
test_windows_provider test? Perhaps splitting up the other provider tests a
bit? As I said, it's not clear to me why the various provider tests need to
have the simple provider setup so often. Could be I just don't know enough.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Received on Wed May 9 06:54:36 2007

This is an archived mail posted to the Subversion Dev mailing list.