On 11.03.2013 11:46, Daniel Shahaf wrote:
> Branko Čibej wrote on Mon, Mar 11, 2013 at 11:25:11 +0100:
>> 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.
>>
>> 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.
> Don't know about java, but we've confused the two kinds before, so
> perhaps:
>
> Index: subversion/include/svn_types.h
> ===================================================================
> --- subversion/include/svn_types.h (revision 1455090)
> +++ subversion/include/svn_types.h (working copy)
> @@ -223,7 +223,7 @@ 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,
> + svn_kind_unknown = 100, /* do not overlap svn_node_kind_t */
>
> /** absent */
> svn_kind_none,
That would work, too. The thing is, I'd rather not invent a whole new
kind type in Java and would much prefer to create a consistent mapping
of both enumerations to the same Java enum.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Received on 2013-03-11 12:18:09 CET