On 18-Jun-07, at 1:20 AM, Troy Curtis Jr wrote:
> On 6/17/07, Toby Thain <toby@smartgames.ca> wrote:
>>
>> On 17-Jun-07, at 8:31 PM, Troy Curtis Jr wrote:
>>
>> > ...
>> > trying to determine whether I can successfully run a Subversion
>> > repository straight out of RAM, but in a caching sort of way
>> such that
>> > the data is written to disk and can thus survive a power failure
>> > (important for version control wouldn't you say? :) )
>>
>> Unless you're prepared to lose data, commits must always hit the
>> disk. So presumably you just want to speed up checkouts?
>>
>
> Absolutely true, which is why using a ram disk is not an option. I
> was more looking at some kind of persistent disk caching...just some
> kind of extension to the current linux disk caching. Some way to tell
> the kernel to always keep these particular set of files or directories
> in the disk cache.
A wacky suggestion: It's possible to configure Subversion to use a
proxy (e.g. Squid). This configuration does not seem to cache
anything at all, which is of course very conservative and safe. I
wonder, though, whether any of Subversion's protocol is theoretically
cacheable - bear with me - if you can imagine a cache that could be
invalidated (using ICP?) when a commit is made*. If this is possible
then it could mean a monstrous speedup to read only operations
(unless your repo was frequently being edited).
I haven't studied how Svn uses HTTP, so I might be totally off target
here, and nor do I know if you could tell Squid to invalidate any
data so cached. Maybe someone on this list knows the answers.
...maybe this is a potential feature request either for the Apache
module or adding caching to svnserve (probably easier). Maybe someone
has even requested it already. I imagine many big sites could use
such a trick?
--Toby
* - Perhaps there is some serious gotcha here with guaranteeing
consistent client view of repo.
>
>> >
>> > This will be a running on a Redhat Enterprise Linux 4 Update 4 OS
>> > being served out via Apache. ...
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jun 18 22:13:50 2007