Julian Foad wrote:
>> Index: subversion/tests/cmdline/lock_tests.py
>> ===================================================================
>> --- subversion/tests/cmdline/lock_tests.py (revision 29765)
>> +++ subversion/tests/cmdline/lock_tests.py (working copy)
>> @@ -1344,10 +1344,17 @@
>> # Then, unlocking the WC path should fail.
>> # ### The error message returned is actually this, but let's worry
>> about that
>> # ### another day...
>> - svntest.actions.run_and_verify_svn2(
>> - None, None, ".*((No lock on path)|(400 Bad Request))", 0,
>> - 'unlock', file_path)
>> + if sbox.repo_url.startswith("http"):
>> + expected_err = ".*(400 Bad Request).*"
>> + exit_code = 1
>> + else:
>> + expected_err = ".*(No lock on path).*"
>> + exit_code = 0
>
> Why should this command return a failure code on one RA layer and a
> success code on another? It seems to me that Subversion is wrong, not
> the test.
>
> We could say, "This is only a regression test, so it should test for the
> current behaviour." I don't much like that: I would prefer either for it
> to ignore the exit code, or preferably for us to fix Subversion right
> now to be consistent.
+1
> If we do what your patch does, then please insert a comment saying "###
> This is merely testing for the current behaviour of exit codes, not the
> desired behaviour."
Or perhaps mark the test as XFail() for particular RA layers?
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2008-03-07 15:22:17 CET