Re: svn_client_status5() and depth

On 18.08.2010 21:58, Bert Huijben wrote:

>> 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.

Well, it might have been intended, but it didn't work that way. It
worked as if you would pass TRUE. Since you pass FALSE, the behavior is
not the same as in 1.6.x.
And shouldn't the old APIs stay compatible? To stay compatible with the
old APIs, you would have to pass TRUE in that wrapper.
Or am I missing something important here?

>
>> And what I don't understand: why the extra parameter at all?
>> If the param is set to TRUE unconditionally, then the behavior seems to
>> be the very same as in 1.6.x:
>> If the depth is less than the depth of the WC, it behaves the same as if
>> the param is FALSE. Only if the depth is deeper then the param has any
>> effect - setting the param to TRUE *ignores* deeper depths.
>>
>> So from my point of view, that parameter isn't necessary: the behavior
>> can be configured by using the depth parameter alone.
>
> Well.. that depends on what is the ambient depth of the directory and what
> you try to do with it. If the directory has depth children, passing depth
> infinity should be seen as depth children and depth files as depth files.

Why? If I pass depth infinity, I *want* the depth infinity, not depth
children. If I want the depth of the WC, I can pass depth unknown.
That's what the depth 'unknown' is for: to specify that the depth of the
WC should be used instead. If I pass a specific depth, I want that depth
and not something else.

> svn status -u was designed to show what svn up would do, and that really
> needs the current behavior to work correctly. I think that is the behavior
> older clients want. (But thanks for opening the discussion on that!)
>
>> Also, since this is a readonly operation, the naming 'depth_is_sticky'
>> isn't very good. Even confusing.
>
> Actually the name is 'depth_as_sticky'.
>
>>
>> Ok, reading my text above again, I think I'm not very clear why I think
>> the parameter isn't necessary. So I'll try again:
>>
>> depth sticky
>> <= WC depth FALSE 1.6.x == 1.7 : data for depth
>> <= WC depth TRUE 1.6.x == 1.7 : data for depth
>> > WC depth FALSE 1.6.x data for depth, 1.7 data for
> WCdepth
>> > WC depth TRUE 1.6.x data for depth, 1.7 data for depth
>>
>> Also, if a client wants the data only for the WC depth, passing a depth
>> of 'unknown' will do exactly that, no matter what the sticky is set to.
>>
>> So: every outcome of that API can be triggered by specifying the depth
>> alone. So why not get rid of the sticky param and always do as if it was
>> set to TRUE?
>
> Note that depth is used for more than just this filtering on the ra layer.
> It also applies on what nodes of your local working copy are shown. It did
> work as a filter there.
>
> Are you sure you can mimic that without the extra Boolean?
> (I certainly don't see any of this in your table)

I don't understand: what exactly are you missing from that table above?
Can you maybe provide me that part of the table, and I'll fill in the
data that's returned.

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net