On Tue, Aug 17, 2010 at 3:45 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> On 08/17/2010 01:42 PM, Stefan Küng wrote:
>> Maybe I don't understand that change:
>> --depth specifies a depth to use for the command. If I want the command
>> to use the depth of the working copy, I specify an unknown depth or none
>> at all. But if I specify a depth, I would assume the command to respect
>> that depth and return the info with that depth.
>> So why should the -u flag not use the specified depth?
>
> --depth is a filtering option -- it can only reduce the scope of an
> operation, it can not expand it.
>
> Bert sez he'll make the behavior optional in the API call so you can make
> use of it. We won't expose it at all in the 'svn' command-line client, but
> TortoiseSVN can get its behavior back. Sound good?
<sarcasm>
Yay for another API flag!
</sarcasm>
I'm starting to wonder if the mission (at the API level) of 'st -u'
and vanilla 'st' has diverged enough that we may want to consider an
API named svn_client_remote_status() or something. It seems a bit
silly to keep extending APIs using various boolean flags[1], in a
manner which eventually leads to both consumer and programmer
confusion. This eventually leads to entry points whose behavior
wildly varies based upon the permutations of the set of flags.
Perhaps status5 (with its 13 parameters) has reached this point?
-Hyrum
[1] I will readily admit to being as guilty of this as anybody else,
but the first step in repentance is recognition, and the next is, uh,
proselyting a new-found vision of The Way things should be.
Received on 2010-08-17 23:42:26 CEST