stef...@apache.org 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.
