You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by 郭锐 <ti...@mail.ustc.edu.cn> on 2008/03/23 07:55:29 UTC
A question about sparse-directories
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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: A question about sparse-directories
Posted by Karl Fogel <kf...@red-bean.com>.
"David Glasser" <gl...@davidglasser.net> writes:
> 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.
郭锐, David's comment makes me think that maybe the first task is to
update notes/sparse-directories.txt to reflect what the code today
actually *does*. There can be a separate section for proposals of what
the code should do in the future, but we should also have a clear
description of today's behavior, and currently these two things are
mixed together in that file.
So, unmixing them might be a good place to start...
Best,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: A question about sparse-directories
Posted by David Glasser <gl...@davidglasser.net>.
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, 郭锐 <ti...@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@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
Re: A question about sparse-directories
Posted by Karl Fogel <kf...@red-bean.com>.
郭锐 <ti...@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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: A question about sparse-directories
Posted by 郭锐 <ti...@mail.ustc.edu.cn>.
Hi Dave,
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
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.
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@gmail.com [mailto:dglasser@gmail.com] On Behalf Of David
> Glasser
> Sent: Monday, March 24, 2008 1:15 AM
> To: 郭锐
> Cc: dev@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
sparse-directories specification.
Rui, Guo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org