On Fri, Mar 7, 2008 at 7:22 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>
> 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
I would like to help with this if I can. If I'm reading things
correctly, ra_local and ra_svn are pretty explicit about not returning
errors on unlock failures. So is the right thing to update ra_neon
and ra_serf to do the same?
>
>
> > 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-03-08 00:07:13 CET