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

Re: svn commit: r16649 - in trunk: build/generator/swig subversion/include

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2005-10-11 21:33:24 CEST

kfogel@collab.net wrote:
>> /** A revision, specified in one of @c svn_opt_revision_kind ways. */
>> typedef struct svn_opt_revision_t
>> {
>> enum svn_opt_revision_kind kind; /**< See svn_opt_revision_kind */
>>- union {
>>- svn_revnum_t number;
>>- apr_time_t date;
>>- } value; /**< Extra data qualifying the @c kind */
>>+ svn_opt_revision_value value; /**< Extra data qualifying the @c kind */
>> } svn_opt_revision_t;
> I had to think about this for a moment before concluding that we don't
> have to do the usual deprecation dance, even though we're "changing" a
> longstanding public struct type here. The change is merely that one
> field's type is now named instead of being anonymously inlined -- and
> this can make *no* possible difference to users of the struct, right?
> Even the struct's raw layout should stay the same.
> I'm stating these things like I know them to be true, but actually I'm
> asking if they are true :-).

Certainly for source compatibility. I think so for binary compatibility;
certainly the layout will stay the same, and I think all the linker symbols
will too but I'm not so certain of that.

- Julian

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 11 21:35:21 2005

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.