On Mon, Jun 30, 2008 at 12:37:25PM -0400, C. Michael Pilato wrote:
>>> After reading the crawler code, I was quite confused. There seems no easy way
>>> to get the depth_is_sticky information. Why does the code work without knowing
>>> the depth_is_sticky information? Server-side magic? It seems that the server
>>> will always push edit to the degree required by 'requested_depth', while the
>>> wc_dir is only used to determine whether full content or just delta is needed.
>>> I did not read the server code very carefully. Correct me if I am wrong.
>>
>> (In a previous mail, I mistakenly referred to this problem as being
>> elsewhere in the code. Sorry for the confusion. I know where we are
>> now.)
>>
>> Uh. Hmmm. That's an interesting question... I think cmpilato is
>> probably better qualified to answer it. Mike? By the way, the full
>> thread is
>>
>> http://subversion.tigris.org/servlets/BrowseList?list=dev&by=thread&from=660362
>>
>> and the message I'm responding to here is:
>>
>> http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=140208
>
> I. Uh. I dunno.
>
> The crawler is responsible for telling the server what the working copy
> contains. The ra_do_update call tells the server what the working copy
> wants. The server gives the client what is needed to become what it
> wants to become. This much I know. I know no more.
>
> Given this, I would assume that the crawler doesn't need to know the
> "depth_is_sticky" bit because that is a facet of the requested operation,
> not the working copy description.
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.
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-01 10:04:32 CEST