[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Daniel Shahaf <d.s_at_daniel.shahaf.co.il>
Date: Sat, 5 Apr 2008 21:41:39 +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.s_at_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?


To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org

Received on 2008-04-05 20:42:51 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.