Daniel Shahaf wrote on Wed, 26 Mar 2008 at 08:08 +0200:
> Karl Fogel wrote on Tue, 25 Mar 2008 at 19:31 -0400:
>> Daniel Shahaf <d.s_at_daniel.shahaf.co.il> writes:
>>> It does add a round trip over neon, but I suspect it shouldn't.
>>>
>>> Specifically, the following PROPFIND request, which neon makes early in
>>> an 'svn up' connection:
>>>
>>> <?xml version="1.0" encoding="utf-8"?>
>>> <propfind xmlns="DAV:">
>>> <prop>
>>> <version-controlled-configuration xmlns="DAV:"/>
>>> <resourcetype xmlns="DAV:"/>
>>> <baseline-relative-path
>>> xmlns="http://subversion.tigris.org/xmlns/dav/"/>
>>> <repository-uuid xmlns="http://subversion.tigris.org/xmlns/dav/"/>
>>> </prop></propfind>
>>>
>>> is sent twice if the patch is applied, and once if it isn't.
>>
>> Ah, thanks. Can you make it cache the UUID whenever it first receives
>> the UUID? That would solve this.
>>
>
> I'll look into it. I see that svn_ra_neon__do_get_uuid() already caches the
> UUID; next, I'll find out whether the baseline-relative-path codepath also
> caches the UUID (if it sees it).
>
I looked into it. Unfortunately, I will not be able to test my hypotheses
soon (I won't have time next week at all), but I'll summarise them here
now.
For neon, I think (hypothesis #1) moving the "insert the UUID to the cache"
logic to svn_ra_neon__get_starting_props (and making __get_baseline_info() go
through __get_starting_props() instead of calling __get_props_resource()
directly) would prevent the duplicate request.
For serf, all requests for UUID go through the generic property retrieval
functions, so I assume (hypothesis #2) that the UUID would always be
put in the cache when it is first seen.
Does this sound right?
Daniel,
who will verify his hypotheses when he has some time again.
---------------------------------------------------------------------
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-27 17:58:04 CET