On 17.12.2012 11:25, Daniel Shahaf wrote: > [email protected] wrote on Mon, Nov 26, 2012 at 00:21:26 -0000: >> Author: stefan2 >> Date: Mon Nov 26 00:21:26 2012 >> New Revision: 1413451 >> >> URL: http://svn.apache.org/viewvc?rev=1413451&view=rev >> Log: >> On the cache-server branch. >> >> * BRANCH-README: add >> >> Added: >> subversion/branches/cache-server/BRANCH-README >> >> Added: subversion/branches/cache-server/BRANCH-README >> URL: >> http://svn.apache.org/viewvc/subversion/branches/cache-server/BRANCH-README?rev=1413451&view=auto >> ============================================================================== >> --- subversion/branches/cache-server/BRANCH-README (added) >> +++ subversion/branches/cache-server/BRANCH-README Mon Nov 26 00:21:26 2012 >> @@ -0,0 +1,109 @@ >> +Goal >> +==== >> + >> +Provide a stand-alone executable that will provide a svn_cache__t >> +implementation based on a single shared memory. The core data >> +structure and access logic can be taken from / shared with today's >> +membuffer cache. The latter shall remain available as it is now. > memcached solves the problem you're stating above, and it's an > independent third-party project. Your solution is specific to > Subversion (it's in libsvn_subr and is not in the public API). If > you're solving the same problem memcached does, why does your solution > need to be specific to svn? Should it be a standalone tool that > Subversion interfaces to as an optional dependency, and any other > memcached consumer can switch to too? > > I don't mean to discourage you from doing this work; I just wonder > whether the non-public parts of libsvn_subr is the right place for > it to live in.
I've been wondering about all this caching, actually. There's memacache, as Daniel mentions, and there's redis, and a bunch of other caching solutions that have different strenghts and weaknesses. Yet here we are, reinventing the wheel (and if I read the mails on the topic correctly, having lots of fun while doing that). It would be much better if fsfs could be configured to use one of several caching servers and then the administrator would worry about the rest. I think it's perfectly fine to require one of them. I realize it's too late to do this for 1.8. But I doubt rolling our own cache server makes any kind of sense. -- Brane -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
