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.
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.
]]]
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
