Stefan Sperling <stsp_at_elego.de> writes:
>> "Commit failed due to blah blah blah ... (svn error 26754)"
>>
>> I'm making up the syntax, but you get the idea. People could search
>> for "svn error 26754" and presumably get helpful hits, and this would
>> remain stable even when we change the human-readable part of the error
>> message.
>
> Attached is a diff that implements this.
Yay!
Before we go farther with this, I'd like to know that no one (epg?)
objects strongly to the overall idea.
I think it's a good compromise between error messages that are
friendly to new readers, and error messages that are searchable and
useful to advanced users and to developers (such as in bug reports).
By now, many people have learned how to ignore a small numeric error
code at the end of a message. For example, many major phone companies
do it in some of their error messages, I suppose for exactly the same
reasons that we're contemplating it.
I wouldn't want to make the trailing bit any larger than this, though.
Two words and a number is pretty unobtrusive, especially in
parentheses.
> It's a bit of a rough change, I had to fix quite a few tests that
> matched end-of-line in expected output. Were possible I simply
> made the expected-output regex eat the new " (svn error xyz)" part.
>
> Also, I'm unsure about whether we should call the error codes
> "svn error codes" or "apr error codes".
"svn error code", because we want people Googling for this to come up
with the Subversion-specific solution to a problem in Subversion, even
when the error code itself is one of the stock APR codes. (I see this
is what you did.)
-Karl
> [[[
>
> Print error codes in error messages.
>
> Proposed by Karl in http://svn.haxx.se/dev/archive-2008-02/0084.shtml
> after he suddenly discovered google et al:
>
> Now that there are search engines, it's possibly an argument for
> including the error code itself in error messages (even though that's
> always been held up as one of those ridiculous things engineers do
> that users hate). So:
>
> "Commit failed due to blah blah blah ... (svn error 26754)"
>
> I'm making up the syntax, but you get the idea. People could search
> for "svn error 26754" and presumably get helpful hits, and this would
> remain stable even when we change the human-readable part of the error
> message.
>
> * subversion/libsvn_subr/error.c
> (SVN_FILE_LINE_UNDEFINED): Include a colon here that used to
> be printed along with a format string which was removed.
> (print_error): Append APR error code along with all error messages.
>
> * subversion/tests/cmdline/switch_tests.py
> (commit_routine_switching, forced_switch_failures): Fix these tests,
> they were broken by the changes made to libsvn_subr/error.c.
>
> * subversion/tests/cmdline/diff_tests.py
> (diff_non_version_controlled_file): ditto
>
> * subversion/tests/cmdline/prop_tests.py
> (inappropriate_props): ditto
>
> * subversion/tests/cmdline/commit_tests.py
> (set_invalid_revprops, start_commit_hook_test, pre_commit_hook_test): ditto
>
> * subversion/tests/cmdline/checkout_tests.py
> (co_with_obstructing_local_adds): ditto
> ]]]
>
> --
> Stefan Sperling <stsp_at_elego.de> Software Developer
> elego Software Solutions GmbH HRB 77719
> Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96
> 13355 Berlin Fax: +49 30 23 45 86 95
> http://www.elego.de Geschaeftsfuehrer: Olaf Wagner
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-02-04 21:04:36 CET