Re: Semantics of --depth: should define WC-depth for omitted-items?

Karl Fogel wrote:
> "Rui, Guo" <timmyguo_at_mail.ustc.edu.cn> writes:
>> new1_path) to check it in the "add_tree_with_depth_files" test
>> case. To my surprise, the depth of new added directory is still
>> infinity. What do you think about this? Do I made a wrong assumption
>> or is it actually a bug?
>
> Hmm. That's a really good question; I'm not sure I know the answer.
> Let me re-ask the question more directly, for people just arriving:
>
> Folks, svn takes the '--depth' option to the other commands besides
> 'checkout' and 'update'. For example, 'svn add --depth=FOO NEWTREE'
> means:
>
> "Add NEWTREE, but only include the parts of it reachable when
> descending as far as depth FOO from the top."
>
> And that is how we behave right now. But the question is, once NEWTREE
> is under version control, should it be at depth=FOO or depth=infinity?
>
> Right now, it's at depth=infinity. While that's useful in some cases, I
> think it might be more consistent, and more in line with user
> expectations, for it to be at depth=FOO.

Adding NEWTREE at depth infinity makes sense.

Adding NEWTREE at depth FOO does not necessarily makes sense in the general
case of using --depth with 'svn add'.

Perhaps there's a middle ground to consider seeking: Adding NEWTREE at
depth (FOO - (depth from TARGET to FOO). Yes, in the case of 'svn add
--depth=FOO NEWTREE', that's depth=FOO. But what about 'svn add --force
--depth=immediates parent=of-NEWTREE' ? Seems in that case you want NEWTREE
added at depth empty, since that's what left of a depth-immediates additive
crawl of its parent directory (the actual target of the operation).

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand