Hyrum K Wright wrote: > Philip Martin wrote: >> Hyrum K Wright writes: >>> Julian, >>> I'm seeing the following XPASSs on trunk: >>> At least one test XPASSED, checking /Users/Hyrum/dev/svn-trunk2/tests.log >>> XPASS: merge_symmetric_tests.py 7: merge_to_and_fro_1_1 >>> XPASS: merge_symmetric_tests.py 8: merge_to_and_fro_1_2 >>> XPASS: merge_symmetric_tests.py 9: merge_to_and_fro_2_1 >>> XPASS: merge_symmetric_tests.py 10: merge_to_and_fro_2_2 >>> XPASS: merge_symmetric_tests.py 11: merge_to_and_fro_3_1 >>> XPASS: merge_symmetric_tests.py 12: merge_to_and_fro_3_2 >>> XPASS: merge_symmetric_tests.py 13: merge_to_and_fro_4_1 >>> XPASS: merge_symmetric_tests.py 14: merge_to_and_fro_4_2 >>> >>> They all look like they are part of your symmetric merge test suite. >>> While I know that code is experimental, it would be nice if they >>> didn't clutter the test output. >> >> The tests PASS when SVN_DEBUG is defined because that causes >> SVN_WITH_SYMMETRIC_MERGE to be defined. In a non-debug build build the >> tests will FAIL. I'm not sure how else these tests could be handled, >> some python to detect SVN_WITH_SYMMETRIC_MERGE (how?) and then SKIP the >> tests? I suppose the --symmetric option could be made conditional and >> the python could detect that. > > Don't unconditionally define SVN_WITH_SYMMETRIC_MERGE with SVN_DEBUG. > We could easily add a configure flag, or interested parties could > define the value at compile time (we used both of these for the Ev2 > shims). The majority of developers aren't using the SYMMETRIC_MERGE > stuff, but they are likely using maintainer mode. We should make > things easier for the most people.
Agreed it's messy as it is. I'll define SVN_WITH_SYMMETRIC_MERGE unconditionally and remove the SVN_DBG statements which were the only reason it was conditional, and remove the 'Wimp' mark-up from those tests. r1348922. - Julian
