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

Re: svn commit: r1132968 - in /subversion/trunk/subversion/include: svn_types.h svn_version.h

From: Greg Stein <gstein_at_gmail.com>
Date: Thu, 23 Jun 2011 16:30:08 -0400

On Thu, Jun 23, 2011 at 15:47, Bert Huijben <bert_at_qqmail.nl> wrote:
>> -----Original Message-----
>> From: Greg Stein [mailto:gstein_at_gmail.com]
>> Sent: donderdag 23 juni 2011 21:01
>> To: dev_at_subversion.apache.org
>> Subject: Re: svn commit: r1132968 - in
>> /subversion/trunk/subversion/include: svn_types.h svn_version.h
>> On Tue, Jun 7, 2011 at 08:14,  <rhuijben_at_apache.org> wrote:
>> > Author: rhuijben
>> > Date: Tue Jun  7 12:14:14 2011
>> > New Revision: 1132968
>> >
>> > URL: http://svn.apache.org/viewvc?rev=1132968&view=rev
>> > Log:
>> > Following up on r1132965, just move the type. This matches how we
>> handled the
>> > problem for svn_error_t.
>> >
>> > * subversion/include/svn_types.h
>> >  (svn_version_t): Add full definition here.
>> >
>> > * subversion/include/svn_version.h
>> >  (svn_version_t): And remove it here.
>> I've been thinking more on this change and absolutely hate it.
>> We have a header DEDICATED to this structure and its concepts. The
>> structure should be in that header file. It makes no sense to have a
>> dedicated header, yet to move its key structure somewhere else.
>> Please revert this change.
> We also have a header file dedicated to svn_error_t and yet it is defined in
> svn_types.h.

Yes. We wanted to avoid recursive includes, per the comment attached
to svn_error_t. That is because svn_error_t is used within

svn_version_t is NOT used within svn_types.h, so there is no need to
disentangle recursive #includes.

> The fact that you personally hate it doesn't add any weight to your other
> arguments.
> I don't see any other strong opinions on this and as you try to teach
> everyone on this list Apache doesn't have per project dictators who say what
> can, can't and must be done. With a veto we ask for a different solution in
> order not to stall the project.

I'm not a dictator, and I didn't attempt to veto this. I'm asking you
to revert a change that myself and a few others disagree with.

I dunno what a "different solution" would be because the move of the
structure didn't solve any problems.

> What solution do you suggest for having a header included everywhere that
> changes on every tag?

Huh? My svn_version.h hasn't changed since June 9th, when I pulled
down this change. It never changes for us developers.

> Can we move the defines that change to a different header that isn't
> included everywhere?
> What kind of forward (typedef) would work to allow keeping the reduced set
> of includes?

I really don't know what defines you're talking about that change.

> I just did what you did in early 1.7 development: reduce the number of
> recursive header includes and this one really helps in the build time:
> Especially for third party projects building on top of Subversion. (Which we
> currently ask to follow trunk)

I don't understand the third party angle here. What does that have to
do with the placement of the svn_version_t structure?

Received on 2011-06-23 22:30:41 CEST

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.