On 01/25/2011 05:00 PM, anatoly techtonik wrote:
> The issues with return codes from command line utility previously
> raised in Bitten project also. I can't understand why you still do not
> think that this is a valid case for a ticket, i.e. that command line
> client doesn't allow to see if a path is absent at specified revision
> in repository? To me the command call is no different from any other
> call (esp. for command line tools), and you can only win from
> consistent scheme for documented return codes.
I'd like, if possible, to reset the tone a bit here.
I have no problems with considering this a valid case for a ticket. By all
means, file the ticket ASAP with my blessing. I agree that it would be
ideal if the command-line client was able to give you all the information it
has regarding an error situation. But "ideal" is not always available, or
not always available in a friendly timeframe. I was mostly just hoping to
give you another possible, more-immediate workaround for your specific
situation.
Back to the problem at hand. Actually, when you build in debug mode, you
get this kind of information via the display on stderr of the apr_err code:
subversion/svn/commit-cmd.c:154: (apr_err=160000)
subversion/libsvn_client/commit.c:846: (apr_err=160000)
svn: Commit failed (details follow):
subversion/libsvn_repos/commit.c:477: (apr_err=160000)
svn: Source url
'/svn:/localhost/svn-test-work/repositories/authz_tests-2/A/mu' is from
different repository
Those apr_err numbers are fixed codes which aren't locale-specific and which
indicate the real error (or errors, since the chain of errors might contain
multiple apr_err codes as different layers wrap and coalesce different error
states). I even wrote a Python bindings script a long time ago to
reverse-map those codes:
$ ./tools/dev/which-error.py 160000
00160000 SVN_ERR_FS_GENERAL
$
Would it be possible to, say, provide a mapping between the apr_err code
space and errorcodes? I'm not sure. I was thinking that the errorcode
space was limited to 32k distinct values, whereas the apr_err code space is
much, much bigger. (Though, we don't use most of it.)
Another approach might be to have a configuration option that says, "I know
this is a release build, but I still really want to see detailed error
messages like we get with debug builds."
Maybe some of these ideas are worthwhile and actionable, maybe not. Maybe
you or someone else has some other, better ideas. So, please do file an
issue about this. And sorry for what might come across as a dismissive
attitude.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2011-01-26 17:21:49 CET