Bert Huijben wrote on Tue, Jul 09, 2013 at 23:00:31 +0200:
> But note that the original patch this discussion started with, did
> exactly the opposite: It decoupled the message and the error code,
> which made svn produce the warning that it didn't understand the
> error.
>
> So: how about agree-i
On Tue, Jul 9, 2013 at 8:04 PM, Joseph Schaefer wrote:
> You've made some interesting and educational points on what veto rights are
> all about Greg, and I appreciate that quite a bit. I do think that it'd be
> worthwhile to document this on the foundation website because it's a common
> poin
You've made some interesting and educational points on what veto rights are all
about Greg, and I appreciate that quite a bit. I do think that it'd be
worthwhile to document this on the foundation website because it's a common
point of frustration for many projects, from well-established ones t
On Tue, Jul 9, 2013 at 6:48 PM, Daniel Shahaf wrote:
> A veto not accompanied by a technical reason is invalid. I am seeking
> consensus on the dev@ list that no technical reason was given. No one
> is going to strip anyone's bits.
Daniel is right on this one:
"To prevent vetos from being used
On Tue, Jul 9, 2013 at 9:48 PM, Daniel Shahaf wrote:
>...
> A veto not accompanied by a technical reason is invalid. I am seeking
> consensus on the dev@ list that no technical reason was given. No one
> is going to strip anyone's bits.
It's a slippery slope that you want to avoid. Very very mu
On 10.07.2013 02:16, Daniel Shahaf wrote:
> On Tue, Jul 09, 2013 at 11:51:09PM +0200, Bert Huijben wrote:
>> (I don't know about our JavaHL users, but I know more than a few SharpSvn
>> users that have checks for specific error codes in their products)
> Do the codes the check for have svn_error_c
On Tue, Jul 09, 2013 at 09:13:07PM -0400, Greg Stein wrote:
> On Tue, Jul 9, 2013 at 9:10 PM, Greg Stein wrote:
> > On Tue, Jul 9, 2013 at 8:15 PM, Daniel Shahaf wrote:
> >>...
> >> So, I submit that your veto lacks a technical basis, and is therefore
> >> invalid,
> >> and has no standing.
> >
On Tue, Jul 9, 2013 at 9:10 PM, Greg Stein wrote:
> On Tue, Jul 9, 2013 at 8:15 PM, Daniel Shahaf wrote:
>>...
>> So, I submit that your veto lacks a technical basis, and is therefore
>> invalid,
>> and has no standing.
>
> You do not get to make that decision. Certainly not unilaterally. If
> y
On Tue, Jul 9, 2013 at 8:15 PM, Daniel Shahaf wrote:
>...
> So, I submit that your veto lacks a technical basis, and is therefore invalid,
> and has no standing.
You do not get to make that decision. Certainly not unilaterally. If
you feel it is invalid, then your course of action is to bring it
ersion.apache.org
> >> Subject: Re: svn commit: r1501371 -
> >> /subversion/trunk/subversion/libsvn_ra_serf/util_error.c
> >>
> >> On 09.07.2013 23:00, Bert Huijben wrote:
> >> > I would welcome a patch to svn_strerror that improves the default
>
On Tue, Jul 09, 2013 at 11:51:09PM +0200, Bert Huijben wrote:
> (I don't know about our JavaHL users, but I know more than a few SharpSvn
> users that have checks for specific error codes in their products)
Do the codes the check for have svn_error_codes.h names?
If yes, they are not relevant ex
On Tue, Jul 09, 2013 at 11:51:09PM +0200, Bert Huijben wrote:
> So: What are we talking about here?
>
> An 'svn'-only user wants to see different error codes?
>
> (Perhaps he added patch over patch to make the numbers more visible in
> MAINTAINER mode?)
First and foremost, can you please quit m
On Wed, Jul 10, 2013 at 1:51 AM, Bert Huijben wrote:
>> -Original Message-
>> From: Branko Čibej [mailto:br...@wandisco.com]
>> Sent: dinsdag 9 juli 2013 23:12
>> To: dev@subversion.apache.org
>> Subject: Re: svn commit: r1501371 -
>> /subver
> -Original Message-
> From: Branko Čibej [mailto:br...@wandisco.com]
> Sent: dinsdag 9 juli 2013 23:12
> To: dev@subversion.apache.org
> Subject: Re: svn commit: r1501371 -
> /subversion/trunk/subversion/libsvn_ra_serf/util_error.c
>
> On 09.07.2013 23:00, B
On 09.07.2013 23:00, Bert Huijben wrote:
> I would welcome a patch to svn_strerror that improves the default
> error for serf specific error codes,
That would effectively make our make implementation details of
libsvn_ra_serf part of the public API. That's a non-strarter IMO.
> or a patch that tr
> -Original Message-
> From: Branko Čibej [mailto:br...@wandisco.com]
> Sent: dinsdag 9 juli 2013 22:48
> To: dev@subversion.apache.org
> Subject: Re: svn commit: r1501371 -
> /subversion/trunk/subversion/libsvn_ra_serf/util_error.c
>
> On 09.07.2013 2
;> Subject: Re: svn commit: r1501371 -
>> /subversion/trunk/subversion/libsvn_ra_serf/util_error.c
>>
>> Bert Huijben wrote on Tue, Jul 09, 2013 at 20:11:57 +0200:
>>> Same as for all previous patches in line:
>>>
>> "All previous patches"? There was one pr
> -Original Message-
> From: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
> Sent: dinsdag 9 juli 2013 22:16
> To: Bert Huijben
> Cc: dev@subversion.apache.org; comm...@subversion.apache.org
> Subject: Re: svn commit: r1501371 -
> /subversion/trunk/subversion/libsvn
Bert Huijben wrote on Tue, Jul 09, 2013 at 20:11:57 +0200:
> Same as for all previous patches in line:
>
"All previous patches"? There was one previous patch along these lines.
> How is this going to help?
I already told you how: it is going to help because API users can't do
anything with t
> -Original Message-
> From: danie...@apache.org [mailto:danie...@apache.org]
> Sent: dinsdag 9 juli 2013 18:41
> To: comm...@subversion.apache.org
> Subject: svn commit: r1501371 -
> /subversion/trunk/subversion/libsvn_ra_serf/util_error.c
>
> Author: danielsh
20 matches
Mail list logo
