On Wed, Aug 18, 2010 at 7:39 PM, Stefan Küng <tortoisesvn_at_gmail.com> wrote:
> On 17.08.2010 23:41, Hyrum K. Wright wrote:
>>
>> 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>
>
> Well, it's either another flag, or use bitmasks. And since bitmasks are not
> allowed anymore, there aren't any more options.
False dichotomy. There are more options than just "add parameters" or
"add bitmasks," one of which I mentioned below: rethinking the roles
of our various APIs, and augmenting *that* instead. (But given your
comments below, I think you're right about this particular case.)
>> 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?
>
> But that would lead to another problem: how would you combine the local
> status and the remote status data? Have the clients merge those two?
Good point. I'm not claiming the above solution is optimal, but that
we need to do some hard thinking about these issues before adding Yet
Another Parameter to the APIs.
-Hyrum
Received on 2010-08-18 22:13:19 CEST