On 18.08.2010 21:58, Bert Huijben wrote:
>> I've checked r986510 and I like to add some comments:
>>
>> In libsvn_client/deprecated.c, svn_client_status4() you pass FALSE for
>> the new sticky param. But that's wrong: in 1.6.x and previous versions,
>> the depth was always respected/enforced. That's why I noticed the
>> changed behavior in the first place!
>> Shouldn't you pass TRUE there?
>
> The not filtering of the nodes was never the intended behavior. It was a
> bug, but had useful behavior for your specific case: explicitly pulling
> unavailable nodes into the working copy.
I've checked the original docs of the svn_client_status4() API. It
nowhere mentions that the intended behavior is to show what an 'svn up'
would do. Actually 'svn up' isn't mentioned at all:
https://svn.apache.org/repos/asf/subversion/tags/1.6.0/subversion/include/svn_client.h
So, no matter if the old behavior is not correct: you can't just change
the behavior and tell people: sorry, that was a bug. Because it wasn't
documented that way so people start to rely on what's documented and on
how it actually works.
If you change the behavior, the API is not compatible anymore.
It's perfectly fine to do that with svn_client_status5() if it gets
documented that way - after all, that's what new APIs are for: not just
changing the params but also the behavior if necessary.
But the older (existing) APIs must not change their behavior.
What's the harm in leaving the behavior in the old APIs even though it's
not what you intended? Please read the docs for the API again - that
intention isn't documented so the old API works as documented.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Received on 2010-08-19 18:16:09 CEST