Patch to use memcache

This is a patch that i am posting, not really for comments (it doesn't
even have a changelog :P) so much as because a bunch of others have
asked me for it.

It adds memcaching of fsfs representations so they are read from the
memcache server instead of disk.

In particular, we cache what the *reprensentation read* returns, and not
the underlying representation. This is just another way of saying we
are caching the results *after* things like undetlification have
occurred, so the result is always a fulltext.

In a world like GCC, where most of the checkouts are of the trunk, and
of the same representations, over and over again, caching this means
most checkouts don't really hit disk at all.

In a world where your fsfs repo is stored on NFS, and you spend a lot of
time making the open/seek/close rpc calls, this is even more of a time
saver.

That said, this approach has problems.

1. Unless we were to do something more advanced (like caching pieces
instead of full-reps), which the current implementation does not, it
requires the entire fulltext representation be buffered in memory at
once so it can be written to the memcache server.

Memcache's protocol has no provisions for reading just *parts* of
values, so the same is true on reading from the cached value as well
(the entire thing must be held in memory).

2. The current implementation requires apr-util 1.3.0, which has
apr_memcache in it. The current apr_memcache implementation has a bug
in regards to large values (see dev@apr for a post i made about this)
that make it unusable. The temporary workaround for this is very easy
(one line), but it requires actually hacking apr-util 1.3.0.

But anyway, here is the patch for those who wanted it.

Note that if you enable the code in rep_read_contents_close, and disable
the code in the rep_read_contents, you'll discover quickly that some
places are not actually closing the streams when they are done, they
just destroy the pool they handed to it, and call it a day.

It'd be nice to fix these places.
Anyway, do what you like with the code :)

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