[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn_client_status5() and depth

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: Tue, 17 Aug 2010 22:42:04 +0200

On 17.08.2010 22:32, C. Michael Pilato wrote:
> On 08/17/2010 12:44 PM, Stefan Küng wrote:
>>> Like I said in r957917, I think we should fix this in a different way.
>>> The difference is between:
>>> What would you get with
>>> * svn up --depth infinity
>>> and
>>> * svn up --set-depth infinity
>>> svn status --depth infinity used to show the last variant, but shows the
>>> first variant now.
>>> I think we should add an option to choose between those two variants. (By
>>> enabling --set-depth on 'svn status' and a similar change to
>>> libsvn_client)
>> But 'svn status' with a --set-depth would mean that this call could
>> change the WC?
>> Until now, 'svn st' didn't change the WC at all, i.e., it was a
>> read-only operation. So is such a change really wanted or necessary?
> Agreed. 'svn st' is a read-only operation, period. But I suspect that Bert
> is saying that the --set-depth option, when applied to 'svn status -u',
> would be merely a way to describe the "mode" of the -u?

Isn't that what --depth is for?
As I understand it, --depth is to specify the depth you want, and
--set-depth is the depth you want the target to set to (i.e., keep that
depth after the operation).

> If that's the case, personally I think it would be a horrendous UI decision.
> Any option that has "set" as its action-word sounds like something's about
> to be changed, which is not what's really going on here.

That's how I understand it: --set-depth sets the depth. But of course
it's likely that I'm wrong here.

> But that said, I believe Bert's change in r957917 was a good one -- a
> correct one -- perfectly in line with the interpretation of the -u option to
> 'svn st' altogether. So I'm interested, Stefan, in understanding why
> TortoiseSVN wants the prior behavior. What's TortoiseSVN trying to tell its
> users with this extra data?

I use this in the "check for modifications" dialog which shows the
status of the whole working copy in a flat view. There's a 'check
repository' button which uses the '-u' flag.
Now, if users have a sparse checkout, they can use the 'check
repository' button and get all the files that are not in their sparse
checkout but in the repository. Then users can right-click on those
files and update those - which is used to populate a sparse checkout.
And also, if new folders are added users can 'extend' their sparse
checkout that way, so those new folders have to show up with an 'svn st
-u -v --depth infinity' so users can actually see that there's something
new in the repository.

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?


   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net
Received on 2010-08-17 22:43:01 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.