> -----Original Message-----
> From: Stefan Sperling [mailto:stsp_at_elego.de]
> Sent: maandag 11 maart 2013 12:59
> To: Branko Čibej
> Cc: Subversion Development
> Subject: Re: Confusion to svn_kind_t!
>
> On Mon, Mar 11, 2013 at 11:25:11AM +0100, Branko Čibej wrote:
> > As I've been updating JavaHL for 1.8, I tripped over the new svn_kind_t
> > enum. Since it not only replaces svn_node_kind_t but also changes the
> > values of the equivalent enumeration constants, maintaining backward
> > compatibility in JavaHL is going to be a bit of a pain.
>
> There have also been (still are?) several bugs on trunk where the wrong
> kind is being used because code erroneously uses a node_kind_t where a
> kind_t is expected and vice versa.
>
> I agree that keeping the existing enumeration values consistent between
> the two types would ease transition and might also prevent bugs.
>
> > Do we really need a new enumeration type just to add a new enum
> > constant? I'd prefer to extend svn_node_kind_t with the symlink value
> > instead.
>
> At this point use of svn_kind_t is very much engrained in libsvn_wc.
> It is not going to be trivial to undo that. So I would say we keep
> the new type but make the enum values for existing node_kind_t values
> consistent.
The original reasoning for adding a new enum was from gstein: Third party tools linking to libsvn_client don't expect new values.
But 1.8 will be the second version with the new enum (it was svn_wc__db_kind_t in 1.7) and we never use svn_kind_symlink the way it was intended.
Mapping the enum values will probably only increase the confusion whenever we really start using the symlink or other future values.
If that is the problem we try to solve, why not just remove svn_kind_t and go back to svn_node_kind_t?
>
> This diff might break existing 1.8 working copies so we should probably
> bump the format number as well...
>
> [[[
> * subversion/include/svn_types.h
> (svn_kind_t): Map kind values that already existed in svn_node_kind_t
> to the same enumeration constants. This makes it easier to transition
> from svn_node_kind_t to svn_kind_t, since svn_kind_t values are now
> backwards compatible with node_kind_t.
> ]]]
We don't need a format bump as the working copy stores a word, not an int.
Bert
>
> Index: subversion/include/svn_types.h
> ==========================================================
> =========
> --- subversion/include/svn_types.h (revision 1455102)
> +++ subversion/include/svn_types.h (working copy)
> @@ -222,9 +222,6 @@ svn__apr_hash_index_val(const apr_hash_index_t
> *hi
> */
> typedef enum svn_kind_t
> {
> - /** something's here, but we don't know what */
> - svn_kind_unknown,
> -
> /** absent */
> svn_kind_none,
>
> @@ -234,6 +231,9 @@ typedef enum svn_kind_t
> /** directory */
> svn_kind_dir,
>
> + /** something's here, but we don't know what */
> + svn_kind_unknown,
> +
> /** symbolic link */
> svn_kind_symlink
>
Received on 2013-03-11 13:15:16 CET