Summary - 1.8.x behaviour Re: Printing error stacks. (was: Re: svn_error_symbolic_name)

2013-04-13 Thread Daniel Shahaf
1.8.x@HEAD plus the r1467440,r1467450,r1467481 group in STATUS behaves as follows in maintainer mode: % $svnadmin upgrade / subversion/svnadmin/svnadmin.c:1925, subversion/libsvn_repos/repos.c:1555, subversion/libsvn_repos/repos.c:1461, subversion/libsvn_repos/repos.c:1423, subversion/libsvn_subr/

Re: Printing error stacks. (was: Re: svn_error_symbolic_name)

2013-04-13 Thread Daniel Shahaf
Stefan Sperling wrote on Sat, Apr 13, 2013 at 10:39:50 +0200: > On Sat, Apr 13, 2013 at 03:23:32AM +0300, Daniel Shahaf wrote: > > % $svnadmin create / > > svnadmin: E200011: Repository creation failed > > svnadmin: E200011: Could not create top-level directory > > svnadmin: E200011: '/' exists and

Re: Printing error stacks. (was: Re: svn_error_symbolic_name)

2013-04-13 Thread Bert Huijben
In non-maintainer mode errors should be targeted at *users*. The more cryptic error codes and all caps strings we put in errors the less readable / understandable the messages become. And the more likely users are to contact support or to call the product not user friendly. These errors shou

RE: Printing error stacks. (was: Re: svn_error_symbolic_name)

2013-04-13 Thread Bert Huijben
+1 Bert From: Ivan Zhakov Sent: 13-4-2013 10:44 To: Daniel Shahaf; dev@subversion.apache.org; C. Michael Pilato; Julian Foad Subject: Re: Printing error stacks. (was: Re: svn_error_symbolic_name) On Sat, Apr 13, 2013 at 12:39 PM, Stefan Sperling wrote: > On Sat, Apr 13, 2013 at 03:23:32AM +0

Re: Printing error stacks. (was: Re: svn_error_symbolic_name)

2013-04-13 Thread Ivan Zhakov
On Sat, Apr 13, 2013 at 12:39 PM, Stefan Sperling wrote: > On Sat, Apr 13, 2013 at 03:23:32AM +0300, Daniel Shahaf wrote: >> % $svnadmin create / >> svnadmin: E200011: Repository creation failed >> svnadmin: E200011: Could not create top-level directory >> svnadmin: E200011: '/' exists and is non-

Re: Printing error stacks. (was: Re: svn_error_symbolic_name)

2013-04-13 Thread Stefan Sperling
On Sat, Apr 13, 2013 at 03:23:32AM +0300, Daniel Shahaf wrote: > % $svnadmin create / > svnadmin: E200011: Repository creation failed > svnadmin: E200011: Could not create top-level directory > svnadmin: E200011: '/' exists and is non-empty > (E200011 = DIR_NOT_EMPTY) > % > > Daniel I like it. C

Re: Printing error stacks. (was: Re: svn_error_symbolic_name)

2013-04-12 Thread Daniel Shahaf
Stefan Sperling wrote on Sat, Apr 13, 2013 at 01:55:01 +0200: > On Fri, Apr 12, 2013 at 02:34:26PM -0400, C. Michael Pilato wrote: > > svn: E180003: Unable to connect to a repository at URL > > 'file:///home/cmpilato/tests/arch' > > svn: E180012: Unable to open an ra_local session to URL > > svn: E

Re: Printing error stacks. (was: Re: svn_error_symbolic_name)

2013-04-12 Thread Stefan Sperling
On Fri, Apr 12, 2013 at 02:34:26PM -0400, C. Michael Pilato wrote: > svn: E180003: Unable to connect to a repository at URL > 'file:///home/cmpilato/tests/arch' > svn: E180012: Unable to open an ra_local session to URL > svn: E180001: Unable to open repository 'file:///home/cmpilato/tests/arch' > (

Re: Printing error stacks. (was: Re: svn_error_symbolic_name)

2013-04-12 Thread Ben Reser
On Fri, Apr 12, 2013 at 11:53 AM, Daniel Shahaf wrote: > Another idea: avoid printing the (apr_err=) part if it's the same code as the > line above it (which should be the common case): > > subversion/svn/checkout-cmd.c:168 (apr_err=SVN_ERR_RA_LOCAL_REPOS_OPEN_FAILED) > subversion/libsvn_client/ch

Re: Printing error stacks. (was: Re: svn_error_symbolic_name)

2013-04-12 Thread Daniel Shahaf
On Fri, Apr 12, 2013 at 02:34:26PM -0400, C. Michael Pilato wrote: > Daniel, I find the current error display really ... weighty, for lack of a > better term. It's difficult to pick out the meat of the message amongst the > overwhelming amount of repetitive, all-caps symbolic names of error codes.

Printing error stacks. (was: Re: svn_error_symbolic_name)

2013-04-12 Thread C. Michael Pilato
Daniel, I find the current error display really ... weighty, for lack of a better term. It's difficult to pick out the meat of the message amongst the overwhelming amount of repetitive, all-caps symbolic names of error codes. Something to consider: omit the symbolic name from the printed error l