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

Re: svn commit: r40417 - in trunk: . subversion/include subversion/include/private subversion/libsvn_client subversion/libsvn_subr subversion/libsvn_wc

From: Greg Stein <gstein_at_gmail.com>
Date: Mon, 9 Nov 2009 09:11:46 -0500

On Mon, Nov 9, 2009 at 09:01, Branko ─îibej <brane_at_xbc.nu> wrote:
> Greg Stein wrote:
>> On Sun, Nov 8, 2009 at 05:17, Stefan Sperling <stsp_at_elego.de> wrote:
>>> On Sun, Nov 08, 2009 at 07:30:36AM +0100, Branko Cibej wrote:
>>>> Verdict: -1, please revert this change.
>>> +1 on revert, and simply removing #include <svn_debug.h> from
>>> svn_types.h and requiring people who use SVN_DBG to include svn_debug.h
>>> manually.
>> I put the include into svn_types.h to make our lives easier. Without
>> that, then we'll end up with svn_debug.h scattered around (as noted by
>> Arfrever's removal of them).
>> There should be NO PROBLEM including a private header from a public
>> one, if that inclusion only happens *for us*.
> Well ... Yeah, I guess, sure, as long as no-one who builds tools on top
> of an installed Subversion #defines SVN_DEBUG in their build. Now I know
> of no good reason to do such a thing; but it could happen.
> So in the end, its a choice between telling said user in an ugly way
> that she should leave off defining SVN_DEBUG (file not found:
> private/svn_debug.h), or just silently ignoring that. Or generating
> svn_types.h.
> Frankly at this point I can't be bothered to think things through enough
> to care; as long as the "fix" got reverted.


Well, nobody should be defining symbols in our namespace. I think our
API story has always been pretty clear on that. So I'm quite fine with
it failing for people when they do that.

And meanwhile: we get easier development.


Received on 2009-11-09 15:12:15 CET

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