[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1665437 - /subversion/trunk/subversion/include/svn_fs.h

From: Branko Čibej <brane_at_wandisco.com>
Date: Tue, 10 Mar 2015 13:54:35 +0100

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
Received on 2015-03-10 13:55:55 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.