RE: Confusion to svn_kind_t!

We don't store those skels in 1.8 as we switched to the new combined
conflict skels.

The only place where you see them is if you use the old entries
functions as we somehow defined that struct to have the raw skel (while
only using it as boolean).

I don't think we have to bump for that.
(We still read them during upgrade of course)

Bert From: Branko Čibej
Sent: ‎12-‎3-‎2013 18:34
To: Subversion Development
Subject: Re: Confusion to svn_kind_t!
So I've started the merge of svn_kind_t into svn_node_kind_t and have
run across a more fundamental kind of conflict that I can't resolve
without the help of the authors of the tree-conflict storage.

Here's the problem: the WC code has a mechanism for converting
enumeration values used in code to tokens used by the database. This
mechanism uses a conversion table. For the vast majority of uses, the
table looks like this:

[from subversion/libsvn_wc/token-map.h]

static const svn_token_map_t kind_map[] = {
  { "file", svn_kind_file }, /* MAP_FILE */
  { "dir", svn_kind_dir }, /* MAP_DIR */
  { "symlink", svn_kind_symlink }, /* MAP_SYMLINK */
  { "unknown", svn_kind_unknown }, /* MAP_UNKNOWN */
  { NULL }
};

However, for tree conflict storage, we have:

[from subversion/libsvn_wc/tree_conflicts.c]

static const svn_token_map_t node_kind_map[] =
{
  { "none", svn_node_none },
  { "file", svn_node_file },
  { "dir", svn_node_dir },
  { "", svn_node_unknown },
  { NULL }
};

Note that the first table is for svn_kind_t, whereas the second is for
svn_node_kind_t (which supposedly shouldn't have been used in the WC
code in the first place); but that's not the issue, the biggest problem
is the difference in mapping svn_kind_unknown and svn_node_unknown.

I could leave the difference as-is, but frankly it seems silly to be
inconsistent in the way we represent essentially the same things in the
database. In my opinion, this calls for a WC-version bump before we
branch 1.8.

Other opinions please?

-- Brane

-- 
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com