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

Re: A question about sparse-directories

From: Karl Fogel <kfogel_at_red-bean.com>
Date: Mon, 24 Mar 2008 02:01:06 -0400

郭锐 <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

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.