Greg Hudson wrote:
> On Thu, 2006-01-26 at 02:25 +0000, Julian Foad wrote:
>
>>That's definitely a serious consideration. For a while you made me think this
>>is not worth doing if it is going to cause any such harm. Then I went on to
>>check the usage of our "deprecated" functions and found another whole class of
>>errors that could have been automatically detected. If we don't take the
>>opportunity to use automated checks whenever we can (without too much adverse
>>effect) then we'll suffer.
>
> How, exactly, are we suffering from using our deprecated functions?
> That's just work we've accidentally deferred until 2.0 when we get rid
> of them.
We're not necessarily suffering in any immediate way from using our deprecated
functions - you're right in most cases that it's just deferred work - but:
* In some cases the replacement API provides some improved behaviour which we
believe we are using but in fact we are not using in some part of the program.
For example, svn_wc_process_committed2() recurses via the forwarding function
svn_wc_process_committed() which means that its new "remove_lock" flag is lost
on recursion. It actually seems to achieve the right result, and presumably if
it hadn't this would have been picked up by functional testing, but it is easy
to envisage a similar situation in which some aspect of new behaviour was
missing in certain scenarios that hadn't been tested.
* If there are cases where no use at all is yet being made of a new API,
there's a fair chance that it won't have been tested at all and won't work
properly. (That's true for both revised APIs and completely new APIs.)
* My point was really that we suffer bugs - such as the error leaks that I
found - from not using automated checks that we could easily use. The use of
deprecated functions was just an example of another class of problems that can
be detected and that made me realise the value of such detection; it doesn't
matter whether they can result in actual bugs for that argument to hold.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jan 26 17:05:33 2006