On Thu, Jul 03, 2008 at 10:40:02AM +0800, Rui, Guo wrote:
> On Wed, Jul 02, 2008 at 04:44:31PM -0400, Karl Fogel wrote:
> > "Rui, Guo" <timmyguo_at_mail.ustc.edu.cn> writes:
> > > I am now convinced that it is just a server magic: the server will send the
> > > modification up to the degree constrained by "requested_depth" while the
> > > reported "wc_depth" (the wc_dir in my original post was just a typo) is only
> > > used as a reference to determine whether the full content or just the delta is
> > > needed. The 'depth_is_sticky' is relevant because if the depth is not to be
> > > updated, we just don't need the content of those does not exist in the wc.
> > > This is okay because we have another filter to filter out the redundant
> > > information. But since the server support svn_depth_exclude now, we can makes
> > > it work better by explicitly exclude the unneeded path upon report. This is a
> > > potential performance issue similar to issue 2918 but with a different cause.
> > >
> > > The above is more a deduction than the result of carefully analysing the
> > > server code. So, again, correct me if I'm wrong.
> >
> > Actually, what you're saying makes sense to me. If the path is excluded
> > on the client side, then the server shouldn't send any data for it.
> Good. I'll try to fix this problem later.
After a second thought, I think I'll not fix this in my gsoc project. Because
this work should be done in server side, rather than the crawler logic.
For example, we build a wc by the following commands:
svn co --depth empty http://server/greek_tree
svn up --depth empty A
So, we want to prevent the server from sending the possible modification
within A upon 'svn up'. If we choose to explicitly exclude the subtree as I
mentioned in the previous post, how can we know what is to be excluded?
Remember that we know nothing about the subtree except the name of the root.
We can only pass some more information to the server (e.g. the depth_is_stick
flag) and relies on the server to do the work.
If we designed the depth scheme in a simpler way at the beginning, we may have
other alternatives. For example, three kinds of depth may be enough: excluded,
leaf(files) and infinity. And I think it will be beneficial to record the
excluded items in entries file: adding items that conflict with excluded ones
can be detected earlier. In this alternative scheme, server does not need to
know anything about depth. The only capability that will be beneficial is to
exclude a path when it is requested to.
Rui
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-07-03 15:38:24 CEST