On 23.06.2011 22:59, Bert Huijben wrote: > >> -----Original Message----- >> From: Greg Stein [mailto:gst...@gmail.com] >> Sent: donderdag 23 juni 2011 22:30 >> To: Bert Huijben >> Cc: dev@subversion.apache.org >> Subject: Re: svn commit: r1132968 - in >> /subversion/trunk/subversion/include: svn_types.h svn_version.h >> >> 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? > The defines I'm talking about are > > (I'm not interested in these as these don't change that often, but I add > them here for completeness) > #define SVN_VER_MAJOR 1 > #define SVN_VER_MINOR 7 > #define SVN_VER_PATCH 0 > > But most importantly > #define SVN_VER_TAG " (under development)" > #define SVN_VER_NUMTAG "-dev" > #define SVN_VER_REVISION 0 > > These are redefined by third party distributions that somehow influence how > Subversion is built to make it visible to their users that they are not 100% > the official build.
Please just admit that you're doing this to scratch your personal "half-an-hour-a-day" itch because you have a build setup that continually fiddles with svn_version.h, and leave the third-party hand-waving out of it. For SharpSVN, since it's C#, you can put the actual version info into your assembly metadata and not touch svn_version.h at all, right? -- Brane
