[PATCH] Neon caching (was: Re: [PATCH] Check UUID at RA connection opening)

[Daniel Shahaf <d....@daniel.shahaf.co.il>]

Daniel Shahaf wrote on Sat, 5 Apr 2008 at 17:52 +0300:
> Karl Fogel wrote on Fri, 4 Apr 2008 at 15:37 -0400:
>> Daniel Shahaf <d....@daniel.shahaf.co.il> writes:
>>> Pinging myself.  The patch below is blocked on the Neon UUID caching
>>> fix Karl suggested.  I already wrote that (ra_neon) patch, and will
>>> install Apache today to test it.  (I would have installed it in
>>> advance had I known it would be necessary, of course.)
>> 
>> Thanks for the heads-up, looking forward to it.
>> 
>> -K
>> 
>
> Update.  During some 'update' operations there are three requests for
> the starting_props (two pre-existing and one added by the patch), but
> not all of them are for the UUID; some of them are for DAV:resourcetype
> or for baseline-relative-path.
>
> I assume these are not safe to cache, since many tests failed when
> I tried to cache (in the session struct) the baseline-relative-path in
> addition to the VCC and UUID.  (The VCC is safe to cache:  according to
> lgo, ra_serf caches it.)
>
> Therefore, I suppose caching UUID and VCC only will work (that is: will 
> prevent round-trips when only the VCC and/or UUID are needed), and I will try 
> that next.  However, it will not eliminate duplication completely, as
> far as I see.
>

Attached patch to cache only UUID and VCC.  It passes all tests except
lock_tests 11, where the 'unlock' fails with a 404.  I do not know what
the cause is, yet.  Could it be related to the VCC caching?

Daniel

Re: [PATCH] Neon caching (was: Re: [PATCH] Check UUID at RA connection opening)

[Daniel Shahaf <d....@daniel.shahaf.co.il>]

Daniel Shahaf wrote on Sun, 6 Apr 2008 at 15:38 +0300:
> The attached patch implements this, and passes all tests now.

Ping.  If no one objects, I'll file both patches in the issue tracker.

Daniel




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [PATCH] Neon caching (was: Re: [PATCH] Check UUID at RA connection opening)

[Daniel Shahaf <d....@daniel.shahaf.co.il>]

Daniel Shahaf wrote on Sat, 5 Apr 2008 at 21:41 +0300:
> Daniel Shahaf wrote on Sat, 5 Apr 2008 at 17:52 +0300:
>> Karl Fogel wrote on Fri, 4 Apr 2008 at 15:37 -0400:
>>> Daniel Shahaf <d....@daniel.shahaf.co.il> writes:
>>>> Pinging myself.  The patch below is blocked on the Neon UUID caching
>>>> fix Karl suggested.  I already wrote that (ra_neon) patch, and will
>>>> install Apache today to test it.  (I would have installed it in
>>>> advance had I known it would be necessary, of course.)
>>> 
>>> Thanks for the heads-up, looking forward to it.
>>> 
>>> -K
>>> 
>> 
>> Update.  During some 'update' operations there are three requests for
>> the starting_props (two pre-existing and one added by the patch), but
>> not all of them are for the UUID; some of them are for DAV:resourcetype
>> or for baseline-relative-path.
>> 
>> I assume these are not safe to cache, since many tests failed when
>> I tried to cache (in the session struct) the baseline-relative-path in
>> addition to the VCC and UUID.  (The VCC is safe to cache:  according to
>> lgo, ra_serf caches it.)
>> 
>> Therefore, I suppose caching UUID and VCC only will work (that is: will 
>> prevent round-trips when only the VCC and/or UUID are needed), and I will 
>> try that next.  However, it will not eliminate duplication completely, as
>> far as I see.
>> 
>
> Attached patch to cache only UUID and VCC.  It passes all tests except
> lock_tests 11, where the 'unlock' fails with a 404.  I do not know what
> the cause is, yet.  Could it be related to the VCC caching?

Yes, partly; I should have checked the cache only in __do_get_uuid() and
in __get_vcc(), rather than in __get_starting_props() as I did.

The attached patch implements this, and passes all tests now.

Thanks,

Daniel (the morning edition)