On Thu, Jun 23, 2011 at 15:47, Bert Huijben <b...@qqmail.nl> wrote: >> -----Original Message----- >> From: Greg Stein [mailto:gst...@gmail.com] >> Sent: donderdag 23 juni 2011 21:01 >> To: dev@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, <rhuij...@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_types.h. 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? -g
