Garrett Rooney <rooneg@electricjellyfish.net> writes:
> here's a new version, with a test case.
Applied, with the following tweaks, in revision 656:
* The description string for the new error code should just
describe what the error means. The advice about using "--force"
to override is about a client-specific behavior, not about the
error itself, so it belongs in main.c, where the error is
handled; I moved it there.
* Where main.c handles the error, I changed it to print to stderr,
not stdout. Also noticed some other unrelated places in main.c
where we handle errors to stdout; will fix those in a separate
commit. Don't know why we were doing that; both standard
practice and our test suite clearly prefer stderr.
* I tried the new python test before patching the rest of the code,
just to make sure the test fails without the code fix, but it
passed... Oops. :-)
Turns out a couple of invocations of svntest.main.run_svn()
weren't passing the boolean error_expected flag as the first
argument, so instead "ci" (the commit subcommand) became the
first argument, and got interpreted as setting error_expected of
course. So when Subversion errored out because it was invoked
without a subcommand (because "ci" got used as a flag to
run_svn() instead), run_svn() accepted the error as expected and
the continued on like nothing was wrong. :-)
In general, if you write a test for a bugfix, make sure the test
fails when the bugfix is not present. In this particular case,
that would actually have been the _only_ way to learn that the
whole regression test was in fact not working (also partly due to
the stdout/stderr thing mentioned above).
* Reformatted some of the function calls to be consistent with the
rest of main.c, as described in HACKING.
* Put the issue number (576) into the log message.
Above nits notwithstanding, nice work -- especially the thoroughness
of coverage in the new regression test.
Thanks!,
-Karl
P.S. Enjoyed the deadpan humor of your log message for log_tests.py :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:53 2006