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 <cmpil...@collab.net> CollabNet <> www.collab.net <> Distributed Development On Demand
signature.asc
Description: OpenPGP digital signature
