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/
Justin Erenkrantz wrote on Sat, Apr 13, 2013 at 08:27:52 -0400:
> On Fri, Apr 12, 2013 at 6:28 PM, Peter Samuelson wrote:
>
> > What is the utility of the "(apr_err=_)" suffix there? I think it's
> > better to omit it. Print apr_err= only when it is new information.
> >
>
> +1. -- justin
You
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
On Fri, Apr 12, 2013 at 6:28 PM, Peter Samuelson wrote:
> What is the utility of the "(apr_err=_)" suffix there? I think it's
> better to omit it. Print apr_err= only when it is new information.
>
+1. -- justin
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
+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
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-
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
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
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'
> (
Yay, a bikeshed discussion!
[Daniel Shahaf]
> % $svn upgrade /
> subversion/svn/upgrade-cmd.c:73: (apr_err=_)
> subversion/libsvn_client/upgrade.c:112: (apr_err=_)
> subversion/libsvn_wc/upgrade.c:2194: (apr_err=_)
> subversion/libsvn_wc/wc_db.c:15006: (apr_err=SVN_ERR_WC_INVA
On Sat, Apr 13, 2013 at 12:14 AM, Branko Čibej wrote:
> On 12.04.2013 22:06, Ben Reser wrote:
>> 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):
>>>
>
On 12.04.2013 22:06, Ben Reser wrote:
> 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_
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
Daniel Shahaf wrote on Fri, Apr 12, 2013 at 22:55:59 +0300:
> (And, FTR, the condition in my previous patch should have been just
> "svn_error__is_tracing_link().)
Committed that in r1467440 since it does make the code less cluttered;
we can tweak it further as this thread converges upon other opt
C. Michael Pilato wrote on Fri, Apr 12, 2013 at 15:49:43 -0400:
> On 04/12/2013 03:42 PM, Daniel Shahaf wrote:
> > Actually I got my stack reversed. It's easier to implement a "See
> > below" than a "See above", and of course "See below" means the symbolic
> > error is always immediately above the
On 04/12/2013 03:42 PM, Daniel Shahaf wrote:
> Actually I got my stack reversed. It's easier to implement a "See
> below" than a "See above", and of course "See below" means the symbolic
> error is always immediately above the numeric one:
Eh ... not so thrilling.
--
C. Michael Pilato
CollabNe
Daniel Shahaf wrote on Fri, Apr 12, 2013 at 22:22:18 +0300:
> C. Michael Pilato wrote on Fri, Apr 12, 2013 at 15:16:23 -0400:
> > On 04/12/2013 02:53 PM, Daniel Shahaf wrote:
> > > Another idea: avoid printing the (apr_err=) part if it's the same code as
> > > the
> > > line above it (which should
C. Michael Pilato wrote on Fri, Apr 12, 2013 at 15:16:23 -0400:
> On 04/12/2013 02:53 PM, 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
> >
On 04/12/2013 02:53 PM, 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/checkout.c:1
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.
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
22 matches
Mail list logo
