On 7/1/07, Lieven Govaerts <svnlgo@mobsol.be> wrote:
> glasser@tigris.org wrote:
> > Modified: trunk/subversion/tests/cmdline/commit_tests.py
> > URL: http://svn.collab.net/viewvc/svn/trunk/subversion/tests/cmdline/commit_tests.py?pathrev=25607&r1=25606&r2=25607
> > ==============================================================================
> > --- trunk/subversion/tests/cmdline/commit_tests.py (original)
> > +++ trunk/subversion/tests/cmdline/commit_tests.py Sun Jul 1 14:47:54 2007
> > @@ -1936,16 +1936,8 @@
> > # Now, commit and examine the output (we happen to know that the
> > # filesystem will report an absolute path because that's the way the
> > # filesystem is created by this test suite.
> > - expected_output = [ "Sending "+ iota_path + "\n",
> > - "Transmitting file data .\n",
> > - "Committed revision 2.\n",
> > - "\n",
> > - "Warning: 'post-commit' hook failed (exited with a "
> > - "non-zero exitcode of 1). The following error output "
> > - "was produced by the hook:\n",
> > - "Post-commit hook failed\n",
> > - ]
> > -
> > + expected_output = "Post-commit hook failed"
> > +
> > svntest.actions.run_and_verify_svn(None, expected_output, [],
> > 'ci', '-m', 'log msg', iota_path)
> >
> David,
>
> while I have no problem with the idea of changing 1.4 tests to pass with
> a trunk server, in this case we loose the part that tests the fix for
> issue 2648.
> So I'm negative on this change.
Hmm, OK. My impression was that the main point of the test was to
make sure that the post-commit hook is called at all and that the
warning text comes through; the 2648 change (r22494) is just a detail.
Do you agree that this should be backported even if it isn't
appropriate on trunk?
> Like I said on IRC yesterday, we should do two things:
> - start adding a "@since version" flag on tests, where the version is
> the oldest (active) version for which the test passes.
> - stop changing existing tests to test for changed behavior, which is
> exactly what happened here.
Hmm. Another possibility for when the difference between versions is
merely cosmetic (and I don't think this is very often, since most
message changes are in the client) would be to explicitly check the
requested server version when setting expectations... I'll do that to
this test when I get around to writing the
server-backwards-compatability testing code, probably this weekend.
--dave
--
David Glasser | glasser_at_mit.edu | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 2 17:02:21 2007