[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [RFC] svn propset should require 'force' to set unknown svn: propnames

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Fri, 23 Nov 2012 16:22:24 +0000 (GMT)

Branko Čibej wrote:

> On 23.11.2012 15:35, Julian Foad wrote:
>> In file included from subversion/libsvn_delta/compat.c:36:0:
>> ./subversion/svn_private_config.h:236:7:
> "SVN_QSORT_R_NORMAL_ARG_ORDER" is not defined
[...]
>
> Julian, we've had this discussion before. I'm not going to change the
> accepted way of checking autoconf macros just because you insist on
> turning on warnings about perfectly valid and 15-years standard
> behaviour of the C preprocessor. That by the way is not even turned on
> in maintainer-mode.

You clearly feel very strongly about that.  Fine.  I'm removing "-Wundef" from my local compiler flags now.

I don't "insist" on using that warning; rather I found it useful: in conjunction with a consistent *convention* of testing with "#ifdef" it has occasionally helped me catch bugs in the past.  Yet it is no silver bullet: the opposite kind of bugs can happen too.

I'm fully aware the usage is "perfectly valid" C, but that and being however many years old doesn't by itself mean it's a good idea, of course.

On the other hand, I do believe consistency is important.  Presently Subversion code is self-consistent in using "#ifdef", apart from this one instance, while inconsistent with some (many?) other autoconf users, including APR, which use "#if".  If we still value consistency in this project, we should consider switching all our usage to "#if".  I'm not volunteering to do that.  And I only said "consider" -- I'm not insisting and I don't wish to prolong this discussion.

Ugh, I hate conflict.  Can we talk about some exciting technical design issue next please :-)

- Julian
Received on 2012-11-23 17:23:02 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.