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

cmpilato@tigris.org writes:
> --- trunk/subversion/include/svn_opt.h (original)
> +++ trunk/subversion/include/svn_opt.h Tue Oct 11 07:38:25 2005
> @@ -201,15 +201,20 @@
> svn_opt_revision_head
> };
>
> +/**
> + * A revision value, which can be stored in one of @c svn_opt_revision_kind
> + * ways.
> + */
> +typedef union svn_opt_revision_value {
> + svn_revnum_t number;
> + apr_time_t date;
> +} svn_opt_revision_value;

"@since New in 1.3", if it's going into 1.3, otherwise "1.4".

> /** 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 :-).

-Karl

-- 
www.collab.net  <>  CollabNet  |  Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org