郭锐 <timmyguo_at_mail.ustc.edu.cn> writes:
> 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.
I think the examples in notes/sparse-directories.txt are probably a good
guide, but don't treat it as a rigid specification: if you think of
something better, we can do that instead.
In other words, you're welcome to submit patches to
notes/sparse-directories.txt as well as to code :-).
> 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
> deselecting sub-trees.
> 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
> usability.
Yes. For now, I think we should concentrate on getting the --depth
interfaces to work for deselection. We can worry about aliases later.
> One more question, what is "svn update --depth=empty" supposed to do if the
> sub-tree to fold contains local modification?
That's a good question.
Maybe behave similarly to what 'svn delete' does -- that is, leave the
modified files in place (but in this case, they'd also remain versioned,
unlike with 'svn delete').
-Karl
---------------------------------------------------------------------
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 07:16:39 CET