On 04.03.2015 17:04, Philip Martin wrote:
> Branko Čibej writes:
>
>> And here it is: the whole atomic.c file
>>
>> https://paste.apache.org/2iyN
>>
>> and the diff against current trunk:
>>
>> https://paste.apache.org/cK1R
>>
> I prefer patches to be included in the email. Ideally inline
Branko Čibej writes:
> And here it is: the whole atomic.c file
>
> https://paste.apache.org/2iyN
>
> and the diff against current trunk:
>
> https://paste.apache.org/cK1R
>
I prefer patches to be included in the email. Ideally inline, as far as
I am concerned, or as an attachment.
--
On 04.03.2015 15:26, Branko Čibej wrote:
> On 04.03.2015 14:56, Ivan Zhakov wrote:
>> On 4 March 2015 at 16:48, Philip Martin wrote:
>>> Ivan Zhakov writes:
>>>
I was thinking about similar change, but as far I remember it's not
safe to use svn_atomic__init_once() in error.c, because
>>
On 04.03.2015 16:21, Branko Čibej wrote:
> On 04.03.2015 15:26, Branko Čibej wrote:
>> On 04.03.2015 14:56, Ivan Zhakov wrote:
>>> On 4 March 2015 at 16:48, Philip Martin wrote:
Ivan Zhakov writes:
> I was thinking about similar change, but as far I remember it's not
> safe to u
On 04.03.2015 14:56, Ivan Zhakov wrote:
> On 4 March 2015 at 16:48, Philip Martin wrote:
>> Ivan Zhakov writes:
>>
>>> I was thinking about similar change, but as far I remember it's not
>>> safe to use svn_atomic__init_once() in error.c, because
>>> svn_atomic__init_once() uses svn_error_*() API
On 4 March 2015 at 16:48, Philip Martin wrote:
> Ivan Zhakov writes:
>
>> I was thinking about similar change, but as far I remember it's not
>> safe to use svn_atomic__init_once() in error.c, because
>> svn_atomic__init_once() uses svn_error_*() API. This may lead circular
>> initialization of s
Ivan Zhakov writes:
> I was thinking about similar change, but as far I remember it's not
> safe to use svn_atomic__init_once() in error.c, because
> svn_atomic__init_once() uses svn_error_*() API. This may lead circular
> initialization of svn_error_*() tracing infrastructure.
That does need to
On 04.03.2015 14:31, Ivan Zhakov wrote:
> On 4 March 2015 at 16:07, Branko Čibej wrote:
>> On 04.03.2015 13:50, Ivan Zhakov wrote:
>>> On 4 March 2015 at 11:27, Branko Čibej wrote:
There was some discussion on #svn-dev recently about making the error
location tracing (see libsvn_subr/er
On 4 March 2015 at 16:07, Branko Čibej wrote:
> On 04.03.2015 13:50, Ivan Zhakov wrote:
>> On 4 March 2015 at 11:27, Branko Čibej wrote:
>>> There was some discussion on #svn-dev recently about making the error
>>> location tracing (see libsvn_subr/error.c and svn_error__locate)
>>> thread-safe,
On 04.03.2015 13:50, Ivan Zhakov wrote:
> On 4 March 2015 at 11:27, Branko Čibej wrote:
>> There was some discussion on #svn-dev recently about making the error
>> location tracing (see libsvn_subr/error.c and svn_error__locate)
>> thread-safe, by using platform- and compiler-specific flags for ma
Branko Čibej writes:
> I'll fix the comment ... but a typedef for the svn_atomic__init_once
> handler wouldn't really help, since you can't use that to define a function.
I would use it in the comment:
Implements svn_atomic__init_once_callback_t.
--
Philip Martin | Subversion Committer
WANd
On 4 March 2015 at 11:27, Branko Čibej wrote:
> There was some discussion on #svn-dev recently about making the error
> location tracing (see libsvn_subr/error.c and svn_error__locate)
> thread-safe, by using platform- and compiler-specific flags for making
> the location variables thread-safe.
>
On 04.03.2015 13:23, Philip Martin wrote:
> Branko Čibej writes:
>
>> error stacks look sane. But, before committing the change, I'd like
>> someone else to review the patch because it's just a wee bit tricky in
>> places what with all the #ifdefs.
> Looks OK, a few minor things:
>
>> Index: subve
Branko Čibej writes:
> error stacks look sane. But, before committing the change, I'd like
> someone else to review the patch because it's just a wee bit tricky in
> places what with all the #ifdefs.
Looks OK, a few minor things:
> Index: subversion/libsvn_subr/error.c
> ===
On 04.03.2015 11:18, Philip Martin wrote:
> Branko Čibej writes:
>
>> https://paste.apache.org/fG82
> When I download that patch on my Linux box it ends:
>
> Added: svn:eol-style^M
> ## -0,0 +1 ##^M
> +native^M
> \ No newline at end of property
>
> it has Windows line endings, which is
Branko Čibej writes:
> https://paste.apache.org/fG82
When I download that patch on my Linux box it ends:
Added: svn:eol-style^M
## -0,0 +1 ##^M
+native^M
\ No newline at end of property
it has Windows line endings, which is fine, but it is missing a line on
the final "No newline" l
16 matches
Mail list logo
