(): Include svn_hash.h.
(add_change, test_elide_mergeinfo_catalog, patch_collection_func, test_patch,
rmlocks_change_prop, prop_validation_commit_with_revprop,
test_stream_seek_translated, substitute_and_verify,
test_serialize_prop_conflict): Use svn_hash_gets() instead of
apr_hash_get
Daniel Shahaf wrote on Sat, Mar 23, 2013 at 16:40:30 +0200:
> Nothing to see here; I'm just correcting the commands I used:
>
> spatch -inplace -sp_file 1 subversion/libsvn_subr/*.c
> vim
> :match Error /.\{81\}.*/
> :set aw et so=99 ai si ci sw=2 ts=2 cin
> cino=>2,n2,f0,{2,}0,=2,t0,+4,C1,(0,u0,
Nothing to see here; I'm just correcting the commands I used:
spatch -inplace -sp_file 1 subversion/libsvn_subr/*.c
vim
:match Error /.\{81\}.*/
:set aw et so=99 ai si ci sw=2 ts=2 cin
cino=>2,n2,f0,{2,}0,=2,t0,+4,C1,(0,u0,*300
:map :cn
:map gw%
:map f,frgw%
:vimgrep /svn_hash_sets.*\%81c/ sub
On 20.03.2013 18:51, C. Michael Pilato wrote:
> On 03/20/2013 01:42 PM, Daniel Shahaf wrote:
>> - Do we go through with the change?
> Sure.
Ack.
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
On 03/20/2013 01:42 PM, Daniel Shahaf wrote:
> - Do we move the macro definitions to a private header file (we can have
> svn_foo.h include that private header)?
I don't mind them being public myself. If we're going to call these
functions ourselves for the sake of convenience from a gazillion
On Wed, Mar 20, 2013 at 05:47:11AM +0200, Daniel Shahaf wrote:
> See attached patch. Any objections to doing that (and similar changes
> to the rest of the code)?
So far I see consensus around which #include we should use, but not around
whether we should go through with the change... :-)
- Do w
Branko Čibej wrote:
> On 20.03.2013 16:16, Julian Foad wrote:
>> C. Michael Pilato wrote:
>>
>>> Since svn_hash.h includes svn_types.h, won't this be more like
> replacing the
>>> inclusion of the latter with the inclusion of the former?
>> I'm not sure exactly what you mean, but if we do de
On 20.03.2013 16:16, Julian Foad wrote:
> C. Michael Pilato wrote:
>
>> Since svn_hash.h includes svn_types.h, won't this be more like replacing the
>> inclusion of the latter with the inclusion of the former?
> I'm not sure exactly what you mean, but if we do decide to leave the
> definitions in
C. Michael Pilato wrote:
> On 03/20/2013 09:45 AM, Julian Foad wrote:
>> Branko Čibej wrote:
>>> On 20.03.2013 04:47, Daniel Shahaf wrote:
See attached patch. Any objections to doing that (and similar
changes to the rest of the code)?
>>>
>>> Must we do this just before branching?
On 03/20/2013 09:45 AM, Julian Foad wrote:
> Branko Čibej wrote:
>
>> On 20.03.2013 04:47, Daniel Shahaf wrote:
>>> See attached patch. Any objections to doing that (and similar
>>> changes to the rest of the code)?
>>
>> Must we do this just before branching? I suppose it's a benign change,
>>
Branko Čibej wrote:
> On 20.03.2013 04:47, Daniel Shahaf wrote:
>> See attached patch. Any objections to doing that (and similar changes
>> to the rest of the code)?
>
> Must we do this just before branching? I suppose it's a benign change,
> but it /is/ a lot of code churn.
When I tried doin
On 20.03.2013 04:47, Daniel Shahaf wrote:
> See attached patch. Any objections to doing that (and similar changes
> to the rest of the code)?
Must we do this just before branching? I suppose it's a benign change,
but it /is/ a lot of code churn.
-- Brane
--
Branko Čibej
Director of Subversion
12 matches
Mail list logo
