Daniel Shahaf wrote on Wed, Mar 04, 2015 at 22:51:14 +:
> The script can also show the log (by pressing 'l'), open just that entry
> in $EDITOR to allow editing the Notes field or the parentheticals (by
> pressing 'e'), and add entries to an ignore list so you are never
> prompted for them agai
It has been anonymously hinted to me by Bert and Brane that I should
really think about rewriting backport.pl in a language other than Perl.
Right now, backport.pl can do four things: the nightly mergebot; the
hourly conflicts detector bot; and the two interactive functions from my
earlier email t
Two features of backport.pl that people may not be aware of:
1) backport.pl can automate most of the process of entering a new
nomination.
Here's an example:
[[[
% cd 1.9.x-wc
% ../trunk-wc/tools/dist/nominate.pl r1664080 "Definition should match
declaration."
Index: STATUS
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 wrote on Wed, Mar 04, 2015 at 14:35:02 +0100:
> On 04.03.2015 02:31, danie...@apache.org wrote:
> > +use v5.10.0; # needed for $^V
> > +
> > +# The given/when smartmatch facility, introduced in Perl v5.10, was made
> > +# experimental and "subject to change" in v5.18 (see perl5180delta
On Wed, Mar 4, 2015 at 7:06 PM, Ivan Zhakov wrote:
> On 2 January 2014 at 17:01, wrote:
> > Author: stefan2
> > Date: Thu Jan 2 14:01:43 2014
> > New Revision: 1554807
> >
> > URL: http://svn.apache.org/r1554807
> > Log:
> > Replace the use of svn_fs_node_id + svn_fs_compare_ids with
> > simpl
On 3/4/15 12:46 AM, Branko Čibej wrote:
> On 04.03.2015 07:22, bre...@apache.org wrote:
>> Author: breser
>> Date: Wed Mar 4 06:22:07 2015
>> New Revision: 1663864
>>
>> URL: http://svn.apache.org/r1663864
>> Log:
>> * CHANGES: Bring up to date with 1.9.x branch. This probably needs some more
>>
On 2 January 2014 at 17:01, wrote:
> Author: stefan2
> Date: Thu Jan 2 14:01:43 2014
> New Revision: 1554807
>
> URL: http://svn.apache.org/r1554807
> Log:
> Replace the use of svn_fs_node_id + svn_fs_compare_ids with
> simple calls to svn_fs_node_relation.
>
Stefan,
I was looking to one of com
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
Hi Bert.
I see you are fixing lots of WC bugs at the moment. Are you doing some kind of
testing that we haven't previously been doing, or working with somebody else
who is doing lots of testing? Is there some way we could add regression tests,
or comprehensive component testing, which would cap
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 04.03.2015 02:31, danie...@apache.org wrote:
> Author: danielsh
> Date: Wed Mar 4 01:31:57 2015
> New Revision: 1663842
>
> URL: http://svn.apache.org/r1663842
> Log:
> backport.pl: Track a backwards-incompatible Perl language change.
>
> * tools/dist/backport.pl
> (): Explicitly require vers
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
> ===
All resolved via IRC now.
See r1663940.
- Julian
I (Julian Foad) wrote:
> Branko and Bert, I'm still not sure I understand what is needed for the
> Windows build.
[...]
> Now I don't know which is correct (#ifdef or not) and I understand I do need
> to add svn_hash__[gs]ets to a list of expor
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
Bert forwarded to dev@ from Stefan Hett:
> Bert wrote:
>> I haven’t looked at the full details, but actual merges only store mergeinfo
>> of what is actually merged (includes unaffected tree filtering, filtering
>> what is already merged, etc.). A record only merge is a tool to just
>> register as
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
Branko and Bert, I'm still not sure I understand what is needed for the Windows
build.
>>> -#ifdef SVN_DEBUG
>>> /* In debug builds, the svn_hash_gets macro forwards the parameters
>>> * through this function in order to have parameter type checking,
>>> * particularly for the key. The svn_h
On 04.03.2015 10:03, julianf...@apache.org wrote:
> Author: julianfoad
> Date: Wed Mar 4 09:03:13 2015
> New Revision: 1663896
>
> URL: http://svn.apache.org/r1663896
> Log:
> Redefine the svn_hash_sets macro to match the way svn_hash_gets is defined,
> thus avoiding a backward compatibility probl
Daniel Shahaf wrote:
>> URL: http://svn.apache.org/r1663760
[...]
>> -#define svn_hash_sets(ht, key, val) \
>> - apr_hash_set(ht, key, APR_HASH_KEY_STRING, val)
>> +#define svn_hash_sets(ht, key, val) \
>> + do { [...] } while (0)
>
> Strictly speaking, that's a backwards-inco
On 04.03.2015 09:37, Bert Huijben wrote:
> As noted on irc we have one .def file that is used for release and
> maintenance builds. This generated file has all the function names
> that are published by a .DLL.
>
> If the function is not in the list, we can’t use it in maintainer
> builds from libr
On 04.03.2015 07:22, bre...@apache.org wrote:
> Author: breser
> Date: Wed Mar 4 06:22:07 2015
> New Revision: 1663864
>
> URL: http://svn.apache.org/r1663864
> Log:
> * CHANGES: Bring up to date with 1.9.x branch. This probably needs some more
> proof reading and could use some review by people
Daniel Shahaf wrote:
> Julian Foad wrote on Tue, Mar 03, 2015 at 11:57:26 +:
>> +1. [...]
>
> Fair enough. Committed as r1663837.
Thanks! It looks fine on the 1.9-dev and 1.10-dev docs at
http://subversion.apache.org/docs/
[...]
>> ... put the patch in a file; patch up the whitespace to u
On 04.03.2015 09:38, br...@apache.org wrote:
> Author: brane
> Date: Wed Mar 4 08:38:30 2015
> New Revision: 1663888
>
> URL: http://svn.apache.org/r1663888
> Log:
> * branches/1.9.x/STATUS:
>- Split backport proposals into 1.9.0 release blockers and everything else.
Please review this and ch
As noted on irc we have one .def file that is used for release and maintenance
builds. This generated file has all the function names that are published by a
.DLL.
If the function is not in the list, we can’t use it in maintainer builds from
libraries != libsvn_subr. And if it is in the list,
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.
It turns out that, since we now require APR 1.3+ which p
On 03.03.2015 21:28, julianf...@apache.org wrote:
> Author: julianfoad
> Date: Tue Mar 3 20:28:30 2015
> New Revision: 1663780
>
> URL: http://svn.apache.org/r1663780
> Log:
> * subversion/include/svn_hash.h
> (svn_hash__gets): Remove #if from prototype to match definition.
>
> Modified:
> s
37 matches
Mail list logo
