Re: svn_client_status5 and depth_as_sticky

On 08.07.2011 17:39, C. Michael Pilato wrote:
> On 07/08/2011 10:57 AM, Stefan Küng wrote:
>> Hi,
>>
>> svn_client_status5 has a parameter depth_as_sticky. According to the doc
>> string:
>>
>> If depth_as_sticky is set and depth is not svn_depth_unknown, then the
>> status is calculated as if depth_is_sticky was passed to an equivalent
>> update command.
>>
>> this should report *everything* there is, even items that are excluded in
>> the working copy (svn_depth_exclude) if also 'update' is true and the passed
>> depth is svn_depth_infinity.
>>
>> This used to work a while ago, but now it does not return anything that
>> isn't in the working copy already anymore.
>>
>> I don't know when this stopped working since I don't use this feature very
>> often, but I'm now testing sparse working copies and so I've noticed that it
>> stopped working.
>>
>> May I suggest to also add this option to the CL client? currently 'svn st'
>> does not accept a 'set-depth' or equivalent parameter.
>
> --set-depth is a data-changing option, and 'svn st' doesn't change data.
> That option would be entirely inappropriate for use with the status
> operation. The log message of the commit which added this new API parameter
> (r986510) understood this:
>
> Following up on r957917, make it possible to switch of the ambient depth
> filter when using svn_client_status5, like it is possible with
> svn_client_update3().
>
> Currently we don't expose this information to the svn client, as using
> --set-depth on svn status would be illogical.
>
> I think the natural UI hook would be to bind this to the --depth option,
> allowing an explicitly-set --depth to be honored by the "remote" side of an
> 'svn status --show-updates', while svn_depth_unknown would continue to mean
> "only show me stuff that matches my working copy's ambient depth".
>

Yes, 'set-depth' would be wrong since it doesn't 'set' anything. But
'force-depth' or 'depth-as-sticky' or 'force-remote-depth' or ... would
be fine.

I don't think that option would be inappropriate for 'svn st' - it's a
valid option that actually serves a purpose: you can get a list of
files/folders that are excluded from the working copy.

But the main issue about my post was that the option in the API doesn't
work - maybe we should discuss the part for the CL client in another thread?

Stefan

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