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

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

From: Rui, Guo <timmyguo_at_mail.ustc.edu.cn>
Date: Fri, 18 Apr 2008 02:13:56 +0800

On Thu, Apr 17, 2008 at 01:51:52PM -0400, 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.
>
> Thoughts?
In this specific situation, I think it's hard to say which one is more useful.
The depth of the new sub-tree is more-or-less insignificant comparing to
restricting the operation coverage. So, I would like to vote for the
consistency of the semantics. After all, that was the original reason of this
thread.

Rui, Guo

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-17 20:15:40 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.