On 10.03.2015 13:18, Julian Foad wrote: > Ivan Zhakov wrote: >>> URL: http://svn.apache.org/r1665437 >>> Modified: subversion/trunk/subversion/include/svn_fs.h >>> - * @note Using FS ID based functions is now discouraged and may be fully >>> - * deprecated in future releases. New code should use >>> #svn_fs_node_relation() >>> - * and #svn_fs_node_relation_t instead. >>> + * @note Using FS ID based functions is discouraged since 1.9 and may be >>> + * fully deprecated in future releases. New code should use >>> + * #svn_fs_node_relation() and #svn_fs_node_relation_t instead. >>> */ >>> int >>> svn_fs_compare_ids(const svn_fs_id_t *a, > (and svn_fs_check_related) >> Stefan, >> >> You have proposed to deprecate the FS ID functions [1], but got well >> justified objections [2]. >> >> Are you going to remove these "future deprecation" clauses from >> svn_fs.h or you have alternative ideas regarding this matter? >> >> [1] http://svn.haxx.se/dev/archive-2013-12/0127.shtml >> [2] http://svn.haxx.se/dev/archive-2013-12/0132.shtml > My thoughts: > > The argument that we would want to use these ids for mergeinfo is, in my > opinion, 99% unlikely.
Doesn't matter. We do not, as a rule, deprecate, or warn about possible deprecation of, APIs that we do not provide replacements for in the same release. "May be deprecated in the future" is true for *all* of our public APIs. I see no good reason to put this in docstrings for these particular functions. IMO, either actually deprecate the APIs, or leave out that text. > It doesn't make much sense to deprecate just the id comparison functions > without deprecating all parts of the FS API that deal with node-rev ids: > svn_fs_dirent_t, svn_fs_path_change2_t and svn_fs_node_id(). > > It would be much clearer to write "node-revision" instead of just "node" > where the doc string says things like "if it is the same node". I suggest we > also consider renaming the symbols: s/node/noderev/. The symbol > 'svn_fs_node_same' in particular is confusing. Indeed. We've tried, for 15 years, to be clear about the difference between a "node" and a "node revision". These names are a huge step backwards. -- Brane
