You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Rui, Guo" <ti...@mail.ustc.edu.cn> on 2008/03/31 17:19:29 UTC
depth of the operation vs. depth of the WC
The sparse-directories document is a bit out-dated in several points, which
is gotten cleared during the implementation later.
The design section in that document refers to a "depth" in .svn/entries and
a --depth option which sets the depth value. However, things have been
changed. There are two different depths in the implementation. The first is
the depth of the operation, and the second is just the one mentioned in the
document, the depth of the WC. As a result, the examples of 'svn up --depth'
in the document should be read as 'svn up --set-depth'.
*******
The following knowledge is not gained from the source code (not yet), but
from the help message in the development-build (trunk r30114). Correct me if
my statement is wrong.
*******
The depth of the operation limits the region affected by the operation. That
is what the --depth option in command line actually means. Commands that
accept a -N or -R switch in the old days are all modified to take a --depth
option. A large majority (19 out of 33) of commands gets influenced, much
more than the five listed in the "User interface" section of the document.
The modification should be trivial for commands that do not affect the tree
structure of WC and thus do not deserve further explanation. These take up
15 of the 19 affected commands. The last four commands which (may) need more
attention are checkout, switch, update and merge. (PS: What does the
chagelist command do? It seems to be a new command introduced in the develop
version.)
There is a paragraph in the "Current Status" talking about the depth of
operation:
<===========QUOTE=============>
On the server side, most of the significant changes are in
libsvn_repos/reporter.c. The code that receives update reports now
receives notice of paths that have different depths from their
parent, and of course the overall update operation has a global
depth, which applies whenever not shadowed by some local depth for
a given path.
<=========ENE OF QUOTE========>
This describes how the depth of operation works. The "shadowed" means that,
if a directory in WC is covered by the depth of operation, the depth of that
local path will take control in the operation of the subtree. It implies
that if there is a sub-directory A of infinity depth in current directory, a
'svn up --depth=immediates' will cover the whole subtree beneath A. I'm not
sure if this applies to all other commands. The merge command should be
quite different as described below.
Both the switch and update command have a separate --set-depth option used
to update the depth of WC, or the target of the command (such as current
directory), to be more precise.
However, the checkout command is a bit special. It takes only --depth option
to both constrain the region of operation and set the depth of the WC. In
other words, the semantic of --depth option in the checkout command is
different the one in other commands. A clarification may be needed, either
change a proper name or at least update the description of the option.
The merge command is special that the modification made by this command is
local to the WC and need to be committed. Thus the modification should be
totally accepted by the WC. New subtree will be accepted in a depth of
infinity. The depth of existing tree will not be modified. (Am I right? I'm
not very sure about this.)
How does the --set-depth option influence the subtree when some of the
sub-directories have different depth from the root is an important question.
The examples in the document do not cover this enough, more investigation is
needed.
Rui, Guo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: depth of the operation vs. depth of the WC
Posted by David Glasser <gl...@davidglasser.net>.
You have some useful points here; care to submit patches to the documentation?
--dave
On Mon, Mar 31, 2008 at 10:19 AM, Rui, Guo <ti...@mail.ustc.edu.cn> wrote:
> The sparse-directories document is a bit out-dated in several points, which
> is gotten cleared during the implementation later.
>
> The design section in that document refers to a "depth" in .svn/entries and
> a --depth option which sets the depth value. However, things have been
> changed. There are two different depths in the implementation. The first is
> the depth of the operation, and the second is just the one mentioned in the
> document, the depth of the WC. As a result, the examples of 'svn up --depth'
> in the document should be read as 'svn up --set-depth'.
>
> *******
> The following knowledge is not gained from the source code (not yet), but
> from the help message in the development-build (trunk r30114). Correct me if
> my statement is wrong.
> *******
>
> The depth of the operation limits the region affected by the operation. That
> is what the --depth option in command line actually means. Commands that
> accept a -N or -R switch in the old days are all modified to take a --depth
> option. A large majority (19 out of 33) of commands gets influenced, much
> more than the five listed in the "User interface" section of the document.
> The modification should be trivial for commands that do not affect the tree
> structure of WC and thus do not deserve further explanation. These take up
> 15 of the 19 affected commands. The last four commands which (may) need more
> attention are checkout, switch, update and merge. (PS: What does the
> chagelist command do? It seems to be a new command introduced in the develop
> version.)
>
> There is a paragraph in the "Current Status" talking about the depth of
> operation:
> <===========QUOTE=============>
> On the server side, most of the significant changes are in
> libsvn_repos/reporter.c. The code that receives update reports now
> receives notice of paths that have different depths from their
> parent, and of course the overall update operation has a global
> depth, which applies whenever not shadowed by some local depth for
> a given path.
> <=========ENE OF QUOTE========>
> This describes how the depth of operation works. The "shadowed" means that,
> if a directory in WC is covered by the depth of operation, the depth of that
> local path will take control in the operation of the subtree. It implies
> that if there is a sub-directory A of infinity depth in current directory, a
> 'svn up --depth=immediates' will cover the whole subtree beneath A. I'm not
> sure if this applies to all other commands. The merge command should be
> quite different as described below.
>
>
> Both the switch and update command have a separate --set-depth option used
> to update the depth of WC, or the target of the command (such as current
> directory), to be more precise.
> However, the checkout command is a bit special. It takes only --depth option
> to both constrain the region of operation and set the depth of the WC. In
> other words, the semantic of --depth option in the checkout command is
> different the one in other commands. A clarification may be needed, either
> change a proper name or at least update the description of the option.
> The merge command is special that the modification made by this command is
> local to the WC and need to be committed. Thus the modification should be
> totally accepted by the WC. New subtree will be accepted in a depth of
> infinity. The depth of existing tree will not be modified. (Am I right? I'm
> not very sure about this.)
>
>
> How does the --set-depth option influence the subtree when some of the
> sub-directories have different depth from the root is an important question.
> The examples in the document do not cover this enough, more investigation is
> needed.
>
> 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/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: depth of the operation vs. depth of the WC
Posted by Karl Fogel <kf...@red-bean.com>.
"Rui, Guo" <ti...@mail.ustc.edu.cn> writes:
> Hi dave,
> Of course I would like to contribute a patch. But I'm not very sure about
> some details of my statement yet, especially about how the depth of
> operation works. I may need to check the source code to confirm about this.
> I'll present a patch later when I'm confident enough. ^_^
In r30205 I tried to bring that file up to date. Guo Rui ("Timmy"?),
would you take a look and let me know if anything is still inaccurate?
Thank you,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: depth of the operation vs. depth of the WC
Posted by "C. Michael Pilato" <cm...@collab.net>.
Karl Fogel wrote:
> "Rui, Guo" <ti...@mail.ustc.edu.cn> writes:
>> The second is the --changelist, which seems to honor the depth option in the
>> implementation of "svn update". I'd not had time to read the document about
>> it yet. So, does it interfere with the logic of sparse-directories?
>
> Er, actually I don't know. Do you see any interfering behaviors?
--changelist behaves as a filter, one which applies after depth is taken
into account.
Now 'svn update --changelist' was an oddity in the implementation. If you
see the bottom of notes/changelist-design.txt, you'll find this explanation
of how 'svn update' differs from other libsvn_client APIs which actually
accept a set of changelists as input:
'svn update' presents an interesting challenge, too. The public
svn_client_update3() API takes a list of paths, and returns a list
of revision numbers to which those paths were updated. Each path is
treated as, effectively, a separate update -- complete with output
line that notes the updated-to revision. So, if we do changelist
expansion outside the API, we might turn a single-target operation
into a multi-target one, and the user sees N full updates processes
happen. If we push 'changelists' down into the API, we can fake a
single update with notification tricks. But that starts to get
nasty when we look at non-file changelist support later and the
interactions with externals and such. And if we push 'changelists'
all the way down into the update editor, then we've got a mess of a
whole 'nuther type, downloading tons of server data we won't use,
and so on. [RESOLUTION: Let the command-line client do the
changelist path expansion.]
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: depth of the operation vs. depth of the WC
Posted by "Rui, Guo" <ti...@mail.ustc.edu.cn>.
> --changelist behaves as a filter, one which applies after depth is taken
> into account.
>
> Now 'svn update --changelist' was an oddity in the implementation. If you
> see the bottom of notes/changelist-design.txt, you'll find this
explanation
> of how 'svn update' differs from other libsvn_client APIs which actually
> accept a set of changelists as input:
>
> 'svn update' presents an interesting challenge, too. The public
> svn_client_update3() API takes a list of paths, and returns a list
> of revision numbers to which those paths were updated. Each path is
> treated as, effectively, a separate update -- complete with output
> line that notes the updated-to revision. So, if we do changelist
> expansion outside the API, we might turn a single-target operation
> into a multi-target one, and the user sees N full updates processes
> happen. If we push 'changelists' down into the API, we can fake a
> single update with notification tricks. But that starts to get
> nasty when we look at non-file changelist support later and the
> interactions with externals and such. And if we push 'changelists'
> all the way down into the update editor, then we've got a mess of a
> whole 'nuther type, downloading tons of server data we won't use,
> and so on. [RESOLUTION: Let the command-line client do the
> changelist path expansion.]
>
This mail was buried and I almost missed it. It provides important
information. The --depth option works as a filter (in most situations) too.
And the --set-depth option is mutual exclusive with --depth. We can handle
--changelist in the same way, if needed.
Thank you very much, C. Michael
Rui, Guo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: depth of the operation vs. depth of the WC
Posted by Karl Fogel <kf...@red-bean.com>.
"Rui, Guo" <ti...@mail.ustc.edu.cn> writes:
> Thanks for your update. It explains the "ambient depth" now, which I was
> just wondering about. It looks much better now. However, I still have some
> questions.
>
> The first is about "depth-exclude", a definition you can find in svn_types.h
> while not explicitly documented. The comments say that it's reserved for
> future use and does not have any client side support yet. Shouldn't this be
> documented too if it is a deliberated design? (PS: I can't imagine how could
> it be usefully personally. I'm already happy enough with depth-empty)
It seems someone has documented it now :-). Are you looking at recent
code?
> A formal description of "depth-unknown" may also be beneficial. This may
> looks like this:
> Depth-unknown ---------> Depth not explicitly specified. Svn client should
> map
> it to appropriate default depth in each
> sub-commands.
> However, the server side treats it as depth-infinity
> conservatively.
Done in r30251.
> The second is the --changelist, which seems to honor the depth option in the
> implementation of "svn update". I'd not had time to read the document about
> it yet. So, does it interfere with the logic of sparse-directories?
Er, actually I don't know. Do you see any interfering behaviors?
> The third is about the examples in the document. I suggest all the
> not-implemented examples be retained now that we have a special section for
> them. In addition, those examples should use --set-depth instead of --depth.
> Just fix it :-)
Sure. Could you supply a patch for this? :-)
(See http://subversion.tigris.org/hacking.html#patches.)
> According to the code, the --set-depth is not allowed to use together with
> --depth. Should we have a note for it in the document?
Done in r30251.
> The "affected commands" section should be removed, since all commands that
> take -N or -R are affected which is a large majority. The -N option is not
> always mapped as --depth=files. This makes the description in "API changes"
> section not that accurate. (Minor fault ^_^)
Good point. Also done in r30251.
> Finally, I'm still wondering about the depth of operation (--depth option)
> works. There is a paragraph in "API changes" section as quoted below:
> <===========QUOTE=============>
> On the server side, most of the significant changes are in
> libsvn_repos/reporter.c. The code that receives update reports now
> receives notice of paths that have different depths from their
> parent, and of course the overall update operation has a global
> depth, which applies whenever not shadowed by some local depth for
> a given path.
> <=========ENE OF QUOTE========>
> What does the word "shadowed" mean? Does it mean that, if a directory in WC
> is covered by the depth of operation, the depth of that local path will take
> control in the operation of the subtree? This implies that if there is a
> sub-directory A of infinity depth in current directory, a 'svn up
> --depth=immediates' will cover the whole subtree beneath A, which is not
> proper behavior form my perspective.
It means that if the WC depth is shallower than the requested depth, the
WC depth of course governs. I changed the text, see how it is now.
> And the document also says this:
> <===========QUOTE=============>
> Inside such a working copy, running 'svn up' by itself will update
> only what is already present, but running 'svn up OMITTED_SUBDIR'
> will cause OMITTED_SUBDIR to be brought in at depth-infinity, while
> the rest of the parent working copy remains at its previous depth.
> <=========ENE OF QUOTE========>
> Does this behavior apply to omitted-FILE? If id does, how could the test
> "depth_immediates_bring_in_file" in depth_tests.py pass?
It should apply to OMMITTED_FILE, yes.
In that test, I believe it is the top level that is depth=immediates, so
A/ is depth=empty, and we can bring in A/mu by naming it explicitly.
> Ps: I chose Timothy (Timmy) as my English name in English class and kept
> using it till now. You can call me Timothy or Rui, which is my Chinese name.
> Both are ok. Guo is my family name and I put it at last to follow western
> convention. However, I'm called "Guo Rui" rather than "Rui Guo" in Chinese.
> ^_^
Okay, thanks :-).
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: depth of the operation vs. depth of the WC
Posted by David Glasser <gl...@davidglasser.net>.
On Thu, Apr 3, 2008 at 11:44 PM, Rui, Guo <ti...@mail.ustc.edu.cn> wrote:
> > > The first is about "depth-exclude", a definition you can find in
> svn_types.h
> > > while not explicitly documented. The comments say that it's reserved for
> > > future use and does not have any client side support yet. Shouldn't this
> be
> > > documented too if it is a deliberated design? (PS: I can't imagine how
> could
> > > it be usefully personally. I'm already happy enough with depth-empty)
> >
>
> > It seems someone has documented it now :-). Are you looking at recent
> > code?
>
> If you are referring to the comments in the svn_types.h, yes I have noticed
> this. What I was trying to say is that, why do we have to introduce another
> depth-exclude? Solely for flexibility or expandability?
IMHO, "check out this directory except for this subdirectory" is a
reasonable request to make. And it's very easy to implement on the
server side; the client side suffers from the general "anything
involving the wc is painful" symptom.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: depth of the operation vs. depth of the WC
Posted by Karl Fogel <kf...@red-bean.com>.
"Rui, Guo" <ti...@mail.ustc.edu.cn> writes:
>> In that test, I believe it is the top level that is depth=immediates, so
>> A/ is depth=empty, and we can bring in A/mu by naming it explicitly.
>>
> What I mean is the skipped "A/D/gamma" in that test. Shouldn't it be
> considered OMMITTED_FILE and got brought in too?
No, because we didn't update A/D, and A/D is empty because A/ is at
depth-immediates. We did update A/ explicitly, and that's why A/mu
should be brought in.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: depth of the operation vs. depth of the WC
Posted by David Glasser <gl...@davidglasser.net>.
On Fri, Apr 4, 2008 at 9:20 AM, David Glasser <gl...@davidglasser.net> wrote:
> On Fri, Apr 4, 2008 at 9:02 AM, Rui, Guo <ti...@mail.ustc.edu.cn> wrote:
> > > IMHO, "check out this directory except for this subdirectory" is a
> > > reasonable request to make. And it's very easy to implement on the
> > > server side; the client side suffers from the general "anything
> > > involving the wc is painful" symptom.
> > >
> > > --dave
> > Thanks, Dave.
> > This function request does make sense. However, it may be really tricky in
> > the client side. There will be no .svn/entries to store the depth value if
> > the directory in question does not exist in advance. Current design may have
> > to be modified to store a list of excluded sub-directories in the
> > .svn/entries of the parent directory.
> > There is a possible alternative way to implement this. Setting the depth of
> > root to "files" and cut off the sub-directory in question may satisfy this
> > request. However, the side effect is that, the root will not receive new
> > added sub-directories in future update, which may be unexpected by user.
>
> I implemented it more for the sake of non-'svn' clients doing various
> operations with the reporter. I figure we can build in "exclude"
> capability to wc-ng. (And it would be fine to implement it in the
> current wc model too, similarly to "absent" directories.)
Er, and also you're right that this is pretty important for the
deselection interface when you're deselecting a child of something
that isn't depth-empty (or a directory child of something that is
depth-files).
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: depth of the operation vs. depth of the WC
Posted by David Glasser <gl...@davidglasser.net>.
On Fri, Apr 4, 2008 at 10:42 AM, Rui, Guo <ti...@mail.ustc.edu.cn> wrote:
> > > I implemented it more for the sake of non-'svn' clients doing various
> > > operations with the reporter. I figure we can build in "exclude"
> > > capability to wc-ng. (And it would be fine to implement it in the
> > > current wc model too, similarly to "absent" directories.)
>
> What does wc-ng means? A re-design to libwc? I found a document in notes
> directories for it, but not yet read it.
Yeah, a redesign for libsvn_wc, currently in the design phases.
> > Er, and also you're right that this is pretty important for the
> > deselection interface when you're deselecting a child of something
> > that isn't depth-empty (or a directory child of something that is
> > depth-files).
>
> Maybe I'll try to bring in the depth-exclude in my deselection design if
> there is still enough time after I've done with existing depth values.
> Anyway, this is another story and is not in my plan yet. :-)
Yeah, I'm just not sure that it's good if
$ svn co $REPO/trunk
$ svn-exclude trunk/subdir
suddenly means that "svn up trunk" won't add new subdirs ever.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: depth of the operation vs. depth of the WC
Posted by "Rui, Guo" <ti...@mail.ustc.edu.cn>.
> > > Er, and also you're right that this is pretty important for the
> > > deselection interface when you're deselecting a child of something
> > > that isn't depth-empty (or a directory child of something that is
> > > depth-files).
> >
> > Maybe I'll try to bring in the depth-exclude in my deselection design
if
> > there is still enough time after I've done with existing depth values.
> > Anyway, this is another story and is not in my plan yet. :-)
>
> Yeah, I'm just not sure that it's good if
>
> $ svn co $REPO/trunk
> $ svn-exclude trunk/subdir
>
> suddenly means that "svn up trunk" won't add new subdirs ever.
This would be very bad in my opinion and I wouldn't let it happen. :-)
It's better to leave an empty sub-directory if we can't get rid of it
without negative side effect. The depth-exclude may come to rescue in such a
situation.
And your example here makes me think of something different. Even if the
user explicitly select a subset of subdirectories to work on, it will still
be beneficial to get the user notified if a possible relevant subdirectory
is added after the last update. For example
$ svn co --depth empty $RESPO/trunk
$ svn up A C //work in subdirectory A&C
// Someone added subdirectory D in $RESPO/trunk
// And a later 'svn up' should result in some notification about the added
directory, such as
A,Skipped D
I'm not sure if something like this has already been implemented.
Thank you
Rui, Guo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: depth of the operation vs. depth of the WC
Posted by "Rui, Guo" <ti...@mail.ustc.edu.cn>.
> > I implemented it more for the sake of non-'svn' clients doing various
> > operations with the reporter. I figure we can build in "exclude"
> > capability to wc-ng. (And it would be fine to implement it in the
> > current wc model too, similarly to "absent" directories.)
What does wc-ng means? A re-design to libwc? I found a document in notes
directories for it, but not yet read it.
> Er, and also you're right that this is pretty important for the
> deselection interface when you're deselecting a child of something
> that isn't depth-empty (or a directory child of something that is
> depth-files).
Maybe I'll try to bring in the depth-exclude in my deselection design if
there is still enough time after I've done with existing depth values.
Anyway, this is another story and is not in my plan yet. :-)
Rui, Guo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: depth of the operation vs. depth of the WC
Posted by David Glasser <gl...@davidglasser.net>.
On Fri, Apr 4, 2008 at 9:02 AM, Rui, Guo <ti...@mail.ustc.edu.cn> wrote:
> > IMHO, "check out this directory except for this subdirectory" is a
> > reasonable request to make. And it's very easy to implement on the
> > server side; the client side suffers from the general "anything
> > involving the wc is painful" symptom.
> >
> > --dave
> Thanks, Dave.
> This function request does make sense. However, it may be really tricky in
> the client side. There will be no .svn/entries to store the depth value if
> the directory in question does not exist in advance. Current design may have
> to be modified to store a list of excluded sub-directories in the
> .svn/entries of the parent directory.
> There is a possible alternative way to implement this. Setting the depth of
> root to "files" and cut off the sub-directory in question may satisfy this
> request. However, the side effect is that, the root will not receive new
> added sub-directories in future update, which may be unexpected by user.
I implemented it more for the sake of non-'svn' clients doing various
operations with the reporter. I figure we can build in "exclude"
capability to wc-ng. (And it would be fine to implement it in the
current wc model too, similarly to "absent" directories.)
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: depth of the operation vs. depth of the WC
Posted by "C. Michael Pilato" <cm...@collab.net>.
Rui, Guo wrote:
>> IMHO, "check out this directory except for this subdirectory" is a
>> reasonable request to make. And it's very easy to implement on the
>> server side; the client side suffers from the general "anything
>> involving the wc is painful" symptom.
>>
>> --dave
> Thanks, Dave.
> This function request does make sense. However, it may be really tricky in
> the client side. There will be no .svn/entries to store the depth value if
> the directory in question does not exist in advance. Current design may have
> to be modified to store a list of excluded sub-directories in the
> .svn/entries of the parent directory.
The .svn/entries file already stores skeletal information about
subdirectories, so you wouldn't be breaking new ground here.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: depth of the operation vs. depth of the WC
Posted by "C. Michael Pilato" <cm...@collab.net>.
Rui, Guo wrote:
>>> This function request does make sense. However, it may be really
>>> tricky in the client side. There will be no .svn/entries to store the
>>> depth value if the directory in question does not exist in advance.
>>> Current design may have to be modified to store a list of excluded
>>> sub-directories in the .svn/entries of the parent directory.
>> The .svn/entries file already stores skeletal information about
>> subdirectories, so you wouldn't be breaking new ground here.
> Hi, C. Michael, Thanks for figure this out. I may have made a wrong
> assumption in my previous post. I'm still a freshman here, lacking in
> lots of detail in the implementation.
No problem. (In the grand scheme of the Universe, we're all ultimately
freshmen). I merely wanted to help you learn more of those implementation
details.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
RE: depth of the operation vs. depth of the WC
Posted by "Rui, Guo" <ti...@mail.ustc.edu.cn>.
> > This function request does make sense. However, it may be really tricky
in
> > the client side. There will be no .svn/entries to store the depth value
if
> > the directory in question does not exist in advance. Current design may
have
> > to be modified to store a list of excluded sub-directories in the
> > .svn/entries of the parent directory.
>
> The .svn/entries file already stores skeletal information about
> subdirectories, so you wouldn't be breaking new ground here.
Hi, C. Michael,
Thanks for figure this out. I may have made a wrong assumption in my
previous post. I'm still a freshman here, lacking in lots of detail in the
implementation.
Rui, Guo
>
> --
> C. Michael Pilato <cm...@collab.net>
> CollabNet <> www.collab.net <> Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: depth of the operation vs. depth of the WC
Posted by "Rui, Guo" <ti...@mail.ustc.edu.cn>.
> IMHO, "check out this directory except for this subdirectory" is a
> reasonable request to make. And it's very easy to implement on the
> server side; the client side suffers from the general "anything
> involving the wc is painful" symptom.
>
> --dave
Thanks, Dave.
This function request does make sense. However, it may be really tricky in
the client side. There will be no .svn/entries to store the depth value if
the directory in question does not exist in advance. Current design may have
to be modified to store a list of excluded sub-directories in the
.svn/entries of the parent directory.
There is a possible alternative way to implement this. Setting the depth of
root to "files" and cut off the sub-directory in question may satisfy this
request. However, the side effect is that, the root will not receive new
added sub-directories in future update, which may be unexpected by user.
Anyway, this is just a general discussion. The deselection interface that
I'm working on will achieve the same effect when the root is with depth of
empty or files. However, an empty directory will be left if the root is with
depth of immediates or infinity.
Thank you
Rui, Guo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: depth of the operation vs. depth of the WC
Posted by "Rui, Guo" <ti...@mail.ustc.edu.cn>.
> > The first is about "depth-exclude", a definition you can find in
svn_types.h
> > while not explicitly documented. The comments say that it's reserved for
> > future use and does not have any client side support yet. Shouldn't this
be
> > documented too if it is a deliberated design? (PS: I can't imagine how
could
> > it be usefully personally. I'm already happy enough with depth-empty)
>
> It seems someone has documented it now :-). Are you looking at recent
> code?
If you are referring to the comments in the svn_types.h, yes I have noticed
this. What I was trying to say is that, why do we have to introduce another
depth-exclude? Solely for flexibility or expandability?
>
> > The second is the --changelist, which seems to honor the depth option in
the
> > implementation of "svn update". I'd not had time to read the document
about
> > it yet. So, does it interfere with the logic of sparse-directories?
>
> Er, actually I don't know. Do you see any interfering behaviors?
I've not gotten a chance to figure it out yet. I'll try in a couple of days.
>
> > The third is about the examples in the document. I suggest all the
> > not-implemented examples be retained now that we have a special section
for
> > them. In addition, those examples should use --set-depth instead of
--depth.
> > Just fix it :-)
>
> Sure. Could you supply a patch for this? :-)
>
> (See http://subversion.tigris.org/hacking.html#patches.)
I'll send a patch this night to preserve the existing examples.
Moreover, it would be my next step to come up with use cases to cover as
many situations as possible. I'll post a new thread with a list of cases to
be covered when it is ready, and fill in details later.
> It means that if the WC depth is shallower than the requested depth, the
> WC depth of course governs. I changed the text, see how it is now.
This used to confuse me a lot. However, it looks pretty good now. :-)
>
> > And the document also says this:
> > <===========QUOTE=============>
> > Inside such a working copy, running 'svn up' by itself will update
> > only what is already present, but running 'svn up OMITTED_SUBDIR'
> > will cause OMITTED_SUBDIR to be brought in at depth-infinity, while
> > the rest of the parent working copy remains at its previous depth.
> > <=========ENE OF QUOTE========>
> > Does this behavior apply to omitted-FILE? If id does, how could the test
> > "depth_immediates_bring_in_file" in depth_tests.py pass?
>
> It should apply to OMMITTED_FILE, yes.
>
> In that test, I believe it is the top level that is depth=immediates, so
> A/ is depth=empty, and we can bring in A/mu by naming it explicitly.
>
What I mean is the skipped "A/D/gamma" in that test. Shouldn't it be
considered OMMITTED_FILE and got brought in too?
Thank you
Rui, Guo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: depth of the operation vs. depth of the WC
Posted by "Rui, Guo" <ti...@mail.ustc.edu.cn>.
Hi Karl,
Thanks for your update. It explains the "ambient depth" now, which I was
just wondering about. It looks much better now. However, I still have some
questions.
The first is about "depth-exclude", a definition you can find in svn_types.h
while not explicitly documented. The comments say that it's reserved for
future use and does not have any client side support yet. Shouldn't this be
documented too if it is a deliberated design? (PS: I can't imagine how could
it be usefully personally. I'm already happy enough with depth-empty)
A formal description of "depth-unknown" may also be beneficial. This may
looks like this:
Depth-unknown ---------> Depth not explicitly specified. Svn client should
map
it to appropriate default depth in each
sub-commands.
However, the server side treats it as depth-infinity
conservatively.
The second is the --changelist, which seems to honor the depth option in the
implementation of "svn update". I'd not had time to read the document about
it yet. So, does it interfere with the logic of sparse-directories?
The third is about the examples in the document. I suggest all the
not-implemented examples be retained now that we have a special section for
them. In addition, those examples should use --set-depth instead of --depth.
Just fix it :-)
According to the code, the --set-depth is not allowed to use together with
--depth. Should we have a note for it in the document?
The "affected commands" section should be removed, since all commands that
take -N or -R are affected which is a large majority. The -N option is not
always mapped as --depth=files. This makes the description in "API changes"
section not that accurate. (Minor fault ^_^)
Finally, I'm still wondering about the depth of operation (--depth option)
works. There is a paragraph in "API changes" section as quoted below:
<===========QUOTE=============>
On the server side, most of the significant changes are in
libsvn_repos/reporter.c. The code that receives update reports now
receives notice of paths that have different depths from their
parent, and of course the overall update operation has a global
depth, which applies whenever not shadowed by some local depth for
a given path.
<=========ENE OF QUOTE========>
What does the word "shadowed" mean? Does it mean that, if a directory in WC
is covered by the depth of operation, the depth of that local path will take
control in the operation of the subtree? This implies that if there is a
sub-directory A of infinity depth in current directory, a 'svn up
--depth=immediates' will cover the whole subtree beneath A, which is not
proper behavior form my perspective.
And the document also says this:
<===========QUOTE=============>
Inside such a working copy, running 'svn up' by itself will update
only what is already present, but running 'svn up OMITTED_SUBDIR'
will cause OMITTED_SUBDIR to be brought in at depth-infinity, while
the rest of the parent working copy remains at its previous depth.
<=========ENE OF QUOTE========>
Does this behavior apply to omitted-FILE? If id does, how could the test
"depth_immediates_bring_in_file" in depth_tests.py pass?
Thank you
Rui, Guo
Ps: I chose Timothy (Timmy) as my English name in English class and kept
using it till now. You can call me Timothy or Rui, which is my Chinese name.
Both are ok. Guo is my family name and I put it at last to follow western
convention. However, I'm called "Guo Rui" rather than "Rui Guo" in Chinese.
^_^
PS: Something about my progress. I've done with the hacking & design
document. It'll save the effort on the code later. The notes and READMEs
would be beneficial too. I've started to read some of the periphery code
these days, however, not the core libs yet.
> -----Original Message-----
> From: Karl Fogel [mailto:kfogel@red-bean.com]
> Sent: Thursday, April 03, 2008 6:39 AM
> To: Rui, Guo
> Cc: 'David Glasser'; dev@subversion.tigris.org
> Subject: Re: depth of the operation vs. depth of the WC
>
> "Rui, Guo" <ti...@mail.ustc.edu.cn> writes:
> > Hi dave,
> > Of course I would like to contribute a patch. But I'm not very sure
about
> > some details of my statement yet, especially about how the depth of
> > operation works. I may need to check the source code to confirm about
this.
> > I'll present a patch later when I'm confident enough. ^_^
>
> In r30205 I tried to bring that file up to date. Guo Rui ("Timmy"?),
> would you take a look and let me know if anything is still inaccurate?
>
> Thank you,
> -Karl
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: depth of the operation vs. depth of the WC
Posted by "Rui, Guo" <ti...@mail.ustc.edu.cn>.
Hi dave,
Of course I would like to contribute a patch. But I'm not very sure about
some details of my statement yet, especially about how the depth of
operation works. I may need to check the source code to confirm about this.
I'll present a patch later when I'm confident enough. ^_^
Rui, Guo
>
> You have some useful points here; care to submit patches to the
documentation?
>
> --dave
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org