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

Re: Tests RE: svn commit: r39716 - trunk/subversion/tests/cmdline/svntest

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Sat, 03 Oct 2009 12:11:05 +0100

On Fri, 2009-10-02 at 18:20 +0100, Julian Foad wrote:
> On Fri, 2009-10-02 at 19:16 +0200, Lieven Govaerts wrote:
> > On Fri, Oct 2, 2009 at 7:03 PM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> > > Bert Huijben wrote:
> > >>
> > >> > Author: julianfoad
> > >> > Date: Wed Sep 30 10:57:51 2009
> > >> > New Revision: 39716
> > >> >
> > >> > Log:
> > >> > Make the test suite better about choosing between RA-Neon and RA-Serf.
> > >> > Update the RA type detection functions to reflect that the default is
> > >> > "serf",
> > >> > so that they work when "--http-library" is not specified. Give the test
> > >> > suite's "--http-library" option its own default value ("serf") so that
> > >> > it no longer depends on svn's compiled-in default value.
> > >> >
> > >> > * subversion/tests/cmdline/svntest/main.py
> > >> > (http_library): Rename this variable to preferred_http_library
> > >> > throughout.
> > >> > Clarify its doc string.
> > >> > (is_not_serf): Remove this unused function.
> > >> > (is_ra_type_dav_neon, is_ra_type_dav_serf): No longer assume the
> > >> > default is
> > >> > "neon". Add doc strings.
> > >> > (is_ra_type_svn, is_ra_type_file): Add doc strings.
> > >> > (usage): Mention the default value of --http-library in the help
> > >> > message.
> > >>
> > >> For some reason it seems this change fails two tests on the neon/serf
> > >> buildbots.
> > >>
> > >> Neon:
> > >> XPASS: merge_tests.py 132: replace vs. edit tree-conflicts
> > >>
> > >> And Serf:
> > >> FAIL: merge_authz_tests.py 1: skipped paths get overriding mergeinfo
> > >>
> > >> The first has an:
> > >> XFail(merge_replace_causes_tree_conflict,
> > >> svntest.main.is_ra_type_dav_serf),
> > >> marking and the second a
> > >> SkipUnless(Skip(mergeinfo_and_skipped_paths, svntest.main.is_ra_type_file),
> > >> svntest.main.server_has_mergeinfo),
> > >
> > > I think I have worked out what is wrong.
> > >
> > > Before my change, the test suite's "--http-library" option defaulted to
> > > "neon". Back in the 1.6 days and earlier, that was sensible.
> > >
> > > Because Serf is now the default, I changed the test suite's
> > > "--http-library" option to default to "serf", and also made the test
> > > suite always tell Subversion (via a config option) to prefer to use
> > > whichever library the test suite was told to use. I thought that made
> > > sense.
> > >
> > > What's happening here, I think, is the macosx/neon build-bot is building
> > > Subversion with Neon only, and passing no "--http-library" option to the
> > > test suite. I've changed the default assumption so it now gets it wrong.
> >
> > Yup, that's correct. The two buildbots running on the mac have either
> > ra_neon or ra_serf, not both at the same time.
>
> Fixed, I hope, in r39767. That is, I changed the default back to "neon".
> I may not be able to watch for the result for the next 48 hours or so,
> so please intervene if I've made it worse.
>
> It would be good if the build-bots could both specify the "http-library"
> option as then we could stop it having any default value (make it a
> non-optional option :-) or change its default to serf.

Not sure if this is quite right, yet. My change in r39767 changed the
set of failing tests to a different and smaller set of failing tests but
that doesn't in itself demonstrate it's correct.

For anyone else investigating, note that my original r39716 had an error
that Hyrum corrected in r39722.

I also note that when the test suite fails to run some tests it treats
them as passing, which is a bug that we must fix.

- Julian

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2403192
Received on 2009-10-03 13:11:30 CEST

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.