Daniel Shahaf wrote on Sun, Apr 28, 2013 at 01:13:22 +0300:
> Charles Duffy wrote on Sat, Apr 27, 2013 at 11:42:58 -0500:
> > Is a guarantee provided that configuration files (as referenced via
> > --config-dir) will only be read once (and thus may refer to a non-seekable
> > socket)? If so, this m
Charles Duffy wrote on Sat, Apr 27, 2013 at 11:42:58 -0500:
> Is a guarantee provided that configuration files (as referenced via
> --config-dir) will only be read once (and thus may refer to a non-seekable
> socket)? If so, this may be adequate as-is (and I may end up submitting
> only a test case
It's public domain now, so I believe the problem is solved. If it's
still a problem in the tarball we can remove it, it's not important to
anyone other than devs. If I could have I would have just put it
under contrib, but it's not useful there for functional reasons.
On Sat, Apr 27, 2013 at 4:0
Is a guarantee provided that configuration files (as referenced via
--config-dir) will only be read once (and thus may refer to a non-seekable
socket)? If so, this may be adequate as-is (and I may end up submitting
only a test case and documentation patch guaranteeing this as a
forward-supported se
Gabriela Gibson wrote on Sat, Apr 27, 2013 at 21:05:51 +0100:
> Danielsh suggested on IRC that I clarify the API documentation for the
> function svn_cstring_split().
>
> [[[
>
> Clarify the doxygen documentation for the semantics of the @a sep_chars
> parameter.
>
> * subversion/include/svn_string
Danielsh suggested on IRC that I clarify the API documentation for the
function svn_cstring_split().
[[[
Clarify the doxygen documentation for the semantics of the @a sep_chars
parameter.
* subversion/include/svn_string.h
(svn_cstring_split): Update doxygen comment.
Suggested by: Danielsh
]]
On Sat, Apr 27, 2013 at 7:24 PM, Daniel Shahaf wrote:
> stef...@apache.org wrote on Sat, Apr 27, 2013 at 16:57:10 -:
> > Author: stefan2
> > Date: Sat Apr 27 16:57:10 2013
> > New Revision: 1476623
> >
> > URL: http://svn.apache.org/r1476623
> > Log:
> > On the fsfs-format7 branch: cache chan
Julian Foad wrote on Sat, Apr 27, 2013 at 17:51:22 +0100:
> Daniel Shahaf
> > @@ -197,7 +198,10 @@ svn_ra_svn__skip_leading_garbage(svn_ra_svn_conn_t
> > * contains two elements, an error will result.
> > *
> > * 'B' is similar to 'b', but may be used in the optional tuple
> > specification
stef...@apache.org wrote on Sat, Apr 27, 2013 at 16:57:10 -:
> Author: stefan2
> Date: Sat Apr 27 16:57:10 2013
> New Revision: 1476623
>
> URL: http://svn.apache.org/r1476623
> Log:
> On the fsfs-format7 branch: cache change list containters
You might want to say "changed-paths" to avoid con
Daniel Shahaf
> Bert Huijben wrote:
> Daniel Shahaf wrote on Sat, Apr 27, 2013 at 17:46:42 +0300:
>> Bert Huijben wrote on Sat, Apr 27, 2013 at 16:43:29 +0200:
>>> (Another option would be to start using our tristate enum for this case...
>>> But we made this svnserve<->libsvn_ra_svn api public fo
Daniel Shahaf wrote:
>> URL: http://svn.apache.org/r1476366
>> Log:
>> * subversion/svn/props.c
>> (svn_cl__check_svn_prop_name): Eliminate an unsafe printf format string
>> by using svn_error_create() instead of svn_error_createf().
>
> unsafe printf string == heap underflow == potent
On 27.04.2013 17:01, Daniel Shahaf wrote:
> Daniel Shahaf wrote on Sat, Apr 27, 2013 at 17:46:42 +0300:
>> Bert Huijben wrote on Sat, Apr 27, 2013 at 16:43:29 +0200:
>>> (Another option would be to start using our tristate enum for this case...
>>> But we made this svnserve<->libsvn_ra_svn api publ
Daniel Shahaf wrote on Sat, Apr 27, 2013 at 17:46:42 +0300:
> Bert Huijben wrote on Sat, Apr 27, 2013 at 16:43:29 +0200:
> > (Another option would be to start using our tristate enum for this case...
> > But we made this svnserve<->libsvn_ra_svn api public following our old
> > inter-library rules)
Bert Huijben wrote on Sat, Apr 27, 2013 at 16:43:29 +0200:
> (Another option would be to start using our tristate enum for this case...
> But we made this svnserve<->libsvn_ra_svn api public following our old
> inter-library rules)
+1
And svn_ra_svn__parse_number is now a private API, the public
> -Original Message-
> From: Daniel Shahaf [mailto:danie...@elego.de]
> Sent: zaterdag 27 april 2013 16:36
> To: dev@subversion.apache.org
> Cc: comm...@subversion.apache.org
> Subject: Re: svn commit: r1476563 -
> /subversion/trunk/subversion/svnserve/serve.c
>
> That's wrong since 'B'
That's wrong since 'B' may return SVN_RA_SVN__UNSPECIFIED_NUMBER. In
fact, you reverted r1466659 which was a bugfix.
br...@apache.org wrote on Sat, Apr 27, 2013 at 12:28:44 -:
> Author: brane
> Date: Sat Apr 27 12:28:44 2013
> New Revision: 1476563
>
> URL: http://svn.apache.org/r1476563
> L
Some of these tests are now more robust but completely wrong as the value had 3
defined values where one now has exactly the opposite result and usually breaks
compatibility when using older clients...
The B type has an explicit undefined value for when the value is not sent over
the connectio
Euh, what?!
We cannot distribute GPL code. Please adjust dist.sh and/or release.py or
whatever to rm this from our tarball.
I think it can sit in our svn tree, but am not entirely sure, without a bit
more reading/thought.
Thx,
-g
Author: breser
Date: Fri Apr 26 22:07:04 2013
New Revision: 147641
julianf...@apache.org wrote on Fri, Apr 26, 2013 at 19:59:09 -:
> Author: julianfoad
> Date: Fri Apr 26 19:59:09 2013
> New Revision: 1476366
>
> URL: http://svn.apache.org/r1476366
> Log:
> * subversion/svn/props.c
> (svn_cl__check_svn_prop_name): Eliminate an unsafe printf format string
>
19 matches
Mail list logo
