Thanks for your reply.
I just overlooked the difference in the two examples that I quoted in that
post. And I fixed my question in a following post.
I think the notes file should be treated as a specification. The use cases
listed in that notes file are what things are EXPECTED to work. However, the
implementation may fail to follow the expected behavior by NOW. This may
explain why the soc idea appears.
In fact, I think the use cases listed in the notes file are well defined,
and can server the purpose of de-selection interface very well. However, the
test cases (both the HEAD and r23994) in
subversion/tests/cmdline/depth_tests.py don't cover the situation of
So I assume the code is broken in this specific situation (as shown in issue
#2843) and conclude that there is no need to define a new de-selection
interface, but rather to tune the current implementation to honor the
specification. While not necessarily, an interface like "svn foldtree" could
be provided as the alias of "svn update --depth=empty" to improve the
One more question, what is "svn update --depth=empty" supposed to do if the
sub-tree to fold contains local modification?
> -----Original Message-----
> From: dglasser_at_gmail.com [mailto:dglasser_at_gmail.com] On Behalf Of David
> Sent: Monday, March 24, 2008 1:15 AM
> To: ¹ùÈñ
> Cc: dev_at_subversion.tigris.org
> Subject: Re: A question about sparse-directories
> I haven't had a chance to read your whole message carefully, but note
> at some point that we changed the "update --depth changes depth"
> behavior to require "update --set-depth" instead; I'm not sure if the
> notes file was updated.
Thanks for figuring this. The change may hide somewhere that I failed to
find. And about the notes file, it indeed needs some update, at least to
clarify that the "svn commit" command is also got influenced by the
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-03-24 06:54:11 CET