> -----Original Message-----
> From: Stefan Küng [mailto:tortoisesvn_at_gmail.com]
> Sent: woensdag 18 augustus 2010 11:39
> To: Hyrum K. Wright
> Cc: C. Michael Pilato; Bert Huijben; Subversion Development
> Subject: Re: svn_client_status5() and depth
>
> 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.
>
> > 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?
>
> Bert:
> 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.
> 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.
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)
Bert
>
> Stefan
>
> --
> ___
> oo // \\ "De Chelonian Mobile"
> (_,\/ \_/ \ TortoiseSVN
> \ \_/_\_/> The coolest Interface to (Sub)Version Control
> /_/ \_\ http://tortoisesvn.net
Received on 2010-08-18 22:00:02 CEST