[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: Bert Huijben <bert_at_vmoo.com>
Date: Wed, 18 Aug 2010 18:03:21 -0700

> -----Original Message-----
> From: Stefan Küng [mailto:tortoisesvn_at_gmail.com]
> Sent: woensdag 18 augustus 2010 13:37
> To: Bert Huijben
> Cc: 'Hyrum K. Wright'; 'C. Michael Pilato'; 'Subversion Development'
> Subject: Re: svn_client_status5() and depth

> I don't understand: what exactly are you missing from that table above?
> Can you maybe provide me that part of the table, and I'll fill in the
> data that's returned.

If I have a directory with ambient depth files, I want

svn status -u --depth children .

to show exactly what would change if I would do

svn up --depth children .

As this is the documented behavior for 'svn status -u'. *)

If status is patched as suggested by you, I would see all the directories
that are missing in my local working copy in the 'svn status', but I
wouldn't get them by calling the update. (not what I want)

If I do pass --depth unknown (by not passing --depth) I would not have depth
children, but depth infinity. (not what I want as that shows nodes inside
the directories below the current directory)

Theoretically. I could get the same result by calling something like 'svn
info' to retrieve the depth and then pass that depth..
So that would be

svn status -u --depth files.
But this also removes all the directories that I have explicitly checked out
from the status information.

So there is no way that I can use this documented behavior, without this


*) And that is the reason I didn't pass TRUE. The old behavior is a bug,
which we ought to fix in 1.6.. But then we break TortoiseSVN 1.6, which is
something that I try to avoid. So maybe I should forget that.... (which is
what I did)
Received on 2010-08-19 03:04:48 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.