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.

--dave

On Sun, Mar 23, 2008 at 12:55 AM, ¹ùÈñ <timmyguo_at_mail.ustc.edu.cn> wrote:
> Hi all,
> I'm digging into the sparse-directories design and do some reading more
> carefully. I find an example in spare-directories.txt showing this:
> svn co --depth=immediates http://.../A Awc2
> Creates wc Awc2 with all files and all subdirectories, but
> subdirectories are *empty*.
> Awc2/.svn/entries this_dir depth-immediates
> B
> C
> Awc2/B/.svn/entries this_dir depth-empty
> Awc2/C/.svn/entries this_dir depth-empty
> ...
>
> svn up Awc/B:
> Since B is not yet checked out, add it at depth infinity.
> Awc/.svn/entries this_dir depth-empty
> B
> Awc/B/.svn/entries this_dir depth-infinity
> ...
> Awc/B/E/.svn/entries this_dir depth-infinity
> ...
> ...
>
> While there is a paragraph in the "User interface" section saying this:
> Thus, 'checkout' is identical to 'checkout --depth=infinity', but
> 'switch' and 'update' are not the same as 'switch --depth=infinity' and
> 'update --depth=infinity'. The former update entries according to
> existing depth values, while the latter pull in everything.
>
> Here comes my question, does the example implies that an update to a
> depth-empty directory is designed to implicitly expand the directory to
> depth-infinity, even without a --depth=infinity switch?
>
> On the other hand, I checked the log of the trunk, and found there was a
> sparse-directory branch, which was merged to trunk at r23994 and got deleted
> then. I'll check out the branch and start learning the design from it. I
> hope it is a right way to go.
>
>
> By the way, please allow me to say something irrelevant, to complain about
> an annoying behavior of the svn client, although it's better to post it in a
> separate thread in the user list.
> The problem is that, when 'svn update' applies the modification to the
> working copy, it doesn't honor the ownership & permission that I set
> explicitly. A default group ownership & permission determined by umask is
> used instead. This is quite annoying when I try to debug the code as another
> user.
> This may have been discussed in the user group. Is this a deliberate design
> or some issue to fix?
>
> Thanks for reading.
>
> Rui, Guo
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: dev-help_at_subversion.tigris.org
>
>

-- 
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/