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
Received on 2012-06-11 18:04:31 CEST