You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Philip Martin <ph...@wandisco.com> on 2013/06/03 10:32:51 UTC

Separating deprecated code.

Philip Martin <ph...@wandisco.com> writes:

> Barry Scott <ba...@barrys-emacs.org> writes:
>
>> Index: /Users/barry/wc/svn/svn-1.8.x/subversion/libsvn_wc/tree_conflicts.c
>> ===================================================================
>> --- /Users/barry/wc/svn/svn-1.8.x/subversion/libsvn_wc/tree_conflicts.c	(revision 1484244)
>> +++ /Users/barry/wc/svn/svn-1.8.x/subversion/libsvn_wc/tree_conflicts.c	(working copy)
>> @@ -506,6 +506,7 @@
>>            return SVN_NO_ERROR;
>>          }
>>      }
>> +  *tree_conflict = NULL;
>>    return SVN_NO_ERROR;
>>  }
>
> Committed to trunk and nominated for backport.  Thanks!

This is a patch to svn_wc__get_tree_conflict which is only called from
util.c:svn_wc__status2_from_3 which is itself only called in the main
code from libsvn_wc/deprecated.c and libsvn_client/deprecated.c.  That
makes both svn_wc__get_tree_conflict and svn_wc__status2_from_3 only
necessary for support of the deprecated API.

Should we move the code to deprecated.c?  Should we add DEPRECATED
markings?  conflict-data-test.c also calls svn_wc__get_tree_conflict
which makes it an explicit test of the deprecated code.  If we mark the
functions DEPRECATED do we explicitly disable DEPRECATED warnings in the
test file?

-- 
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download

Re: Separating deprecated code.

Posted by "C. Michael Pilato" <cm...@collab.net>.
On 06/03/2013 04:32 AM, Philip Martin wrote:
> This is a patch to svn_wc__get_tree_conflict which is only called from
> util.c:svn_wc__status2_from_3 which is itself only called in the main
> code from libsvn_wc/deprecated.c and libsvn_client/deprecated.c.  That
> makes both svn_wc__get_tree_conflict and svn_wc__status2_from_3 only
> necessary for support of the deprecated API.
> 
> Should we move the code to deprecated.c?  Should we add DEPRECATED
> markings?  conflict-data-test.c also calls svn_wc__get_tree_conflict
> which makes it an explicit test of the deprecated code.  If we mark the
> functions DEPRECATED do we explicitly disable DEPRECATED warnings in the
> test file?

No strong opinion about the above, but at a minimum we should comment the
two functions to explain their existence.  I mean, even if we do all that
you've asked about, we'd still want to have a comment in place explaining
why we bothered to keep around private, deprecated functions.

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development