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