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

Revprop caching 'n stuff

From: Stefan Fuhrmann <stefanfuhrmann_at_alice-dsl.de>
Date: Wed, 07 Mar 2012 23:40:40 +0100

Hi all,

The revprop caching I introduced in r1296604, -10
plus -7211 (kudos to Daniel) has an issue when it
comes to making long-lived fs_t detect revprop
changes. OTOH, I think that it also provides a huge
performance boost when you use clients like TSVN
that fire a large number of "svn ls -v"-esque queries.

Since the FS API has no means to indicate that a
bunch of small-grained API calls actually belong to
some lager RA request, the revprop-gen file would
have to be checked on *every* revprop read. I.e.
the number of OS-level file operations is the same
as with reading the revprop file directly.
[Note to self: design FS2 such that all data access
is done in the context of query / transaction objects]

So, I made up my mind on how to solve the problem
and this is what I intend to do:

* undo the above-mentioned revs on /trunk
* open a branch and re-apply them
* introduce revprop caching as a third tuning option
   next to "fulltext" and "deltas"
* introduce a new, private API that provides machine-
   wide, named atomics (using the APR shared mem
   API as a basis). Maybe, this will turn out to be useful
   for other sync. issues in the future.
* use the that new svn__named_atomic API to
   replace the revprop-gen file as well as the corresponding
   member in fs_t, i.e. check the revprop gen before
   *every* revprop read.

With that we could at least provide revprop caching
for repos that are accessed from a single machine
using only 1.8+ servers to write revprops. One would
assume that this is the case for must 1.8 users.

If all works out as intended, the changes will soon
be ready for /trunk.

-- Stefan^2.
Received on 2012-03-07 23:41:37 CET

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