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
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
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
This may have been discussed in the user group. Is this a deliberate design
or some issue to fix?
Thanks for reading.
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-23 08:53:45 CET